Duplicates of third-party libraries

[Ben Finney]

"Martin P. Hellwig" <martin.hellwig at 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