"Martin P. Hellwig" <martin.hell...@dcuktec.org> writes: > Ben Finney wrote: > > Along with the duplication this introduces, it also means that any bug > > fixes — even severe security fixes — in the third-party code will not be > > addressed in your duplicate.
> I disagree, what you need is: > - An automated build system for your deliveries, something you should > have anyway > - An method of tracking versions of your dependencies, again something > you should have anyway Those are orthogonal issues. They're good practice, but don't address the problem I'm describing. > - And a policy that you incorporate bug fixes from your dependencies > in your deliveries, something you should do anyway if you are serious > about your product. This omits the heart of the problem: There is an extra delay between release and propagation of the security fix. When the third-party code is released with a security fix, and is available in the operating system, the duplicate in your application will not gain the advantage of that fix until you release a new version of your application *and* that new version makes its way onto the affected computer. That is an additional delay, that only occurs because the hypothetical security bug exists in a duplicate copy of the third party code. That delay is entirely eradicated if your application instead uses a system-installed library; your application then gains the security fix immediately when they upgrade the system-installed library, without the user having to upgrade the application at all. -- \ “I took it easy today. I just pretty much layed around in my | `\ underwear all day. … Got kicked out of quite a few places, | _o__) though.” —Bug-Eyed Earl, _Red Meat_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list