ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Security fixes and merging changes upstream


From: Stuart Hughes
Subject: Re: [Ltib] Security fixes and merging changes upstream
Date: Thu, 20 Oct 2011 08:55:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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.

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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]