Debian discusses vendoring—again

not being very well versed in the security area, the above seems to me to be wrong.

say you have a function that is vulnerable to a privilege escalation, but the application in question is not calling it, so it is "safe".
now assume, another part of the application has a remote code execution bug - boom, the "safe" privilege escalation is all of a sudden not so safe any more...

apart from that, figuring out if a specific function bundled in a dependency is used in a project is orders of magnitudes harder, than figuring out if the project includes a given dependency (which itself can be difficult enough).

Well, for multiple reasons, especially cost-related ones - most developers of FLOSS remain unpaid, or at least not compensated to amounts anywhere near the time they spend on it - very few upstreams provide updates to software releases in such a way that these releases would be suitable for 5 years of security maintenance for a distro (i.e. over 5 years of upstream security maintenance, given the freeze period and also the gap between the latest upstream release and the beginning of the freeze period). Also, many upstreams do not maintain a stable release series either.

> The security bug in the Javascript library might only be exploitable if some particular function is called in some particular situation.

So instead of patching all the copies of the library you now need to audit each and every function call to the vulnerable library, and then still patch it wherever it is vulnerable.

How is it any less work?

> it is upstream's job to check for vulnerabilities

They use npm, realistically they won't check for vulnerabilities.

But even if they did… would they backport the fixes to whatever version debian is using? If not, then it means they can't be used in a stable distribution, because they'd change everything when fixing the security bug as well.

By the way this behaviour is what pushed distributions to drop mysql and move to mariadb en masse. Because oracle doesn't backport fixes and doesn't say what the issues are. They just say "some security issue is fixed" and so you must upgrade.

> so that upstream takes some of the extra costs of bundling

Won't happen. An incredible amount of those js packages are like 20 lines of code, that depend on other 1-3 similarly small packages.

The authors write them and forget about them in several cases. Also many of them write on windows and have no idea about linux.

> then I guess the application is not suitable for inclusion in a distribution with a 5 year

The issue is that following your criteria, basically no js application is suitable for inclusion.

It was a hyperbole. Remains the issue that 13 months is a smaller number than 60.

Except we're not talking about Kubernetes; we're talking about GSA. GSA almost certainly doesn't have an order of magnitude more security people than Debian. And when we're done with GSA, we're going to be talking about an RPG written in an open source JS framework. Part of the problem is there is no line here; the big items may have support, but the small items are what make up most of the system, and they're endless.

I agree, the distro model is something from the world of C where system-provided dynamic libraries are the only way to re-use code, and even there many applications have started vendoring their dependencies.

Languages other than C have proper packaging support, and it's now up to the distros to adapt and make use of the information there is. Hunting down which application uses which library is really not that difficult, unless you're unable to tap into the metadata that a given packaging ecosystem already provides.

I recall years ago that there was some suggestion that debian could similarly use the "Built-Using:" metadata tags for indicating that a given package has some vendored code included in it. The "Built-Using:" tag already exists for tagging the handful of statically compiled packages which cannot avoid vendoring (busybox, various installer components, etc). The existing presumption is that the vendored components are available at package build time as satisfiable "Build-Depends:". The difference in the npm situation is that at build time the dependencies which are to be bundled would not be packaged separately, but would come from $ambiguous_source and the build system would have to be trusted to tag in the "Built-Using:" data.

This type of solution is a find technical solution if not 100% philosophically "clean" in the way debian intends. I would posit that such a solution would be fine for third party package providers and it would be a big step towards solving real world problems if Debian would just outline that this is a best practice for third parties and that first party debian packages would still be required to provide individually packaged packaged dependencies at build time. Softening the the limits on the number of versions of a library can be in the debian repositories would further make this a maintainable situation moving forward with a reasonable path for all various upstreams to cut between major versions of their dependencies.

at any rate thats my .02 maybe someone can tell me why I'm completely wrong :)