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?