Re: [Ltib] Security fixes and merging changes upstream

[address@hidden]

On Thu, Oct 20, 2011 at 3:55 AM, Stuart Hughes <address@hidden> wrote:
> Hi Jon,
>
> Please don't preach.  This is well known, but there are good reasons not to
> do this. Mostly it comes down to time and money, a constraint many of us do
> have.
>
> Also there are many other reasons why this does not get done, so calm down a
> bit.  All this stuff is public and there if you wish to use it, otherwise
> use something else.

A lot of developers are unaware of how badly this problem can bite
them until they build and ship a product that subsequently gets hacked
because of a security bug. In the past we have wasted large amounts of
money recovering from this problem and want to try and avoid it in the
future.

On the positive side the current state of embedded support is far
better than it was five years ago.

I'm just annoyed since forward porting uboot support for the lpc3130
has turned out to be very complicated. NXP wrote their own two stage
boot system which is proving hard to map onto the  model supplied by
current uboot. It can definitely be done but it is significant work.

We want a current kernel and I was able to forward port the NXP kernel
patches in a couple of weeks. But there are changes in the way ARM
ATAGs are passed from uboot into the kernel which are addressed in a
more recent uboot. We are considering switching to a different CPU to
reduce the software load.

A very useful option to add to ltib would be a simple config option to
use the ARM cross compilers already on the system (ie the Linaro ones
in Ubuntu). That would make it much easier to test with the current
compilers. I tried poking around in the scripts to add it but I
couldn't figure out how to do it.


>
> Regards, Stuart
>
> On 19/10/11 14:23, address@hidden wrote:
>>
>> Please submit any publicly useful changes you make to packages
>> upstream and don't carry the patches around in ltib for years. I am
>> spending a month right now trying to forward port the lpc313x uboot
>> changes up to current uboot. I've already brought the lpc313x changes
>> up to the current kernel and need a newer uboot to support it. If
>> those changes had been submitted upstream three years ago when they
>> were written I wouldn't have to be doing this.
>>
>> You really want changes submitted upstream. If you don't do it then
>> you get locked into the version of the program that you patched. You
>> may think that is saving you work by not having to hassle with the
>> submission. And that appearance will be true until a security hole is
>> found and patched in a latter version and your boss tells you that you
>> have to apply the patch. Now you have a mess. The patch is against a
>> latter version of the app that doesn't match your source code.
>>
>> To deal with the mess you either have to create your own private fork
>> where you apply security patches to your old, patched code (this is a
>> tower of cards that will fall as more patches accumulate) or you have
>> to forward port the your initial patch. You could have avoided all of
>> this by simply submitting the initial patch upstream. I've seen people
>> change jobs rather than deal with messes created by private forks.
>>
>> Of course you can choose to ignore the security patches. Do you know
>> how easy it is to hack something when you have the source code of the
>> patch fixing the vulnerability?
>>
>
>



-- 
Jon Smirl
address@hidden