Comment 39 for bug 671027

Revision history for this message
Matt Sealey (mwsealey) wrote :

Yes, we run what you might consider a fork of Maverick with about 5 packages different, and about 10 on top.. but the fact is we use the vast majority of the Ubuntu archive for the convenience of our customers. The less we change the better the board gets supported. If Ubuntu wants to support it or Linaro wants to support it, fine, and we will eventually push to upstream, but the real concept to grasp here is supporting users, and doing the needful things before the "ethically correct" things. Patch now, upstream later. This is not a security bug that needs full disclosure and full cooperation, it's a patch you picked that was broken, which I've fixed and aligned with the support we coded in the first place (which is the *vendor's intent of kernel behavior*)

I don't think the eval is dangerous at all, we know the content of the variable, we know that one of them is going to have slashes in it (hence the comma seperators) and we don't want bash to evaluate too much. I worked this out, this is the best way. If you can get it to work another way, please test it and go ahead, but every test I ran... didn't work. Bash either didn't replace the variable or sed complained. I am well aware of the problems of passing unsanitized, unchecked user arguments to eval, but it can also be said that $(readlink /dev/root) is pretty hard to fake, and not a very common vector to break. In reality we should be using flash_kernel_set_root hook, but in this case, the data is pretty well checked for us too. There is no problem with eval here. I considered the implications, and only used it as a last resort when every other idea fell flat.

The behavior for multiple kernel versions I think should be standard, and it's also the *current* behavior of the script we replace in our custom flash-kernel and ubiquity builds to support our board. Neither way is "more correct", but I prefer that we continue with the seperate versions. Since neither Ubuntu nor Genesi is going to update kernels or change ABIs with that regularity (through lack of support and simple lack of new kernels) it's not going to affect anything.

Understand your concern about "making it Ubuntu's problem", but either way a package that is in the Ubuntu archive marked as being built by Genesi, still becomes Ubuntu's problem for users. Not everyone has a great knowledge of packaging policy, versioning or who to really talk to - we encourage our users to report bugs to the efikamx project first, and I personally assign them to bugs upstream where needed. This is not a bug in user support, it's just a fact of life.