* The software was usually built against specific versions (often modified) of 3rd party libraries. *
That sounds like a disaster waiting to happen... maintaining a different version of libraries outside of their main development trunk means that:
1. Extra steps when a new main version comes out - you have to repatch your differences in.
2. #1 incurs a delay, thus a longer time that your customer are running without patches, which may be a security issue.
3. You won't do #1 at all. Thus you become reliant on old, unmaintained, buggy, security-holey libraries.
The only time I can think this is acceptable is to fix problems that upstream won't fix, or are platform specific (ie, not with your custom software, but with the OS underneath everything).
Patching in new versions isn't usually a huge deal, it's just not worth the trouble. Let's say we're using version 1.2, and we fixed a few bugs in it over the past year. Now version 1.3 is out. Should we upgrade?
Maybe 1.3 fixes a few bugs we haven't encountered yet. But that's unlikely. We've been using it for a year. Far more likely, as in practically a certainty, is that 1.3 will introduce some regression that won't be discovered until it affects some customer.
Not every bug in every program is a security vulnerability, and framing the issue that way distorts things.
Well, if you had uptreamed your fixes against 1.2, they would be in 1.3, wouldn't they ? I find it a poor excuse for not upgrade assuming API and ABI are stable.
It's just laziness. It's easier because that way you don't have to argue with Management. But you also don't educate on the necessity of fixing security issues. Hooray for 1.4 JVM still in production for instance. And it's perfectly ok. Until some breach happens .....
1. We have made changes to the 3rd party source code that we want to ship now, not when they finally let the patch into their source tree.
2. We get new updates from the latest release, patch in our stuff and we are set, quick test on the CI servers and we can ship. Yes, customers may be without the fix for a little while longer...
3. It is actually in our best interest to keep 3rd party libraries at their latest release, if we want secure software. Which is why it is part of our release documents and steps that are required to be followed before we release.
Then what you have is a fork of the library. There is no reason you can't distribute forks of the library (to either your own paths or with your own modified names) using the system package manager.
If you are expecting the person taking your patches to install them to the system, however, that's a whole 'nother ball game, and gets back to the original point: as a system administrator, I have no reason to believe your "better" versions of those libraries are going to interoperate with everything else on the system, and I am then going to have to do a bunch of work doing that isolation myself.
And if you allow the customer to upgrade libraries themselves (or install any version they desire) you'll risk breaking the application. That can be even worse.
That sounds like a disaster waiting to happen... maintaining a different version of libraries outside of their main development trunk means that:
1. Extra steps when a new main version comes out - you have to repatch your differences in.
2. #1 incurs a delay, thus a longer time that your customer are running without patches, which may be a security issue.
3. You won't do #1 at all. Thus you become reliant on old, unmaintained, buggy, security-holey libraries.
The only time I can think this is acceptable is to fix problems that upstream won't fix, or are platform specific (ie, not with your custom software, but with the OS underneath everything).