ltib
[Top][All Lists]
Advanced

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

[Ltib] Security fixes and merging changes upstream


From: address@hidden
Subject: [Ltib] Security fixes and merging changes upstream
Date: Wed, 19 Oct 2011 09:23:19 -0400

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



reply via email to

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