The modern packager’s security nightmare

It's a risk calculation: do I want to risk being vulnerable to 0days, or do I want to risk my application not running for any user because a dependency changed its headers/api?

As software engineers we want to be in control of as much as possible when running our application, to make it as deterministic as possible. For that we select versions of our dependencies, build it, and then test it, and if our tests pass, we release it.

If we would let the OS determine the dependency versions, without testing, what guarantees can we give that our code will work? Do you write tests for future, unknown changes in libraries? Do you write tests with Random, because that's the kind of unpredictability you're introducing?

Why do only *nix folks pull their hair out about this? On Windows programs bundle their dependencies all the time (sometimes even as shared libraries! but without the independent update benefits) and hardly anybody loses sleep over it. Heck, users actually like the fact that it minimizes friction. Nobody claims it's rock-solid security, but does it need to be?

Actually, now that I wrote it above, I think I might have found an answer to my own question: while of course infosec experts will freak out about any vulnerability existing anywhere for even a shred of a nanosecond, in the real world this is really only a big deal for servers, not clients. And I'm guessing this issue affects Linux folks more because servers tend to run on Linux, with security-sensitive software exposed to the open internet all the time. Maybe we need to realize & embrace this trade-off instead of fighting it till the end of time?

(I suppose one could even argue servers don't need this either if all the packages are kept up-to-date anyway; I guess that might also be debatable, but it's beside my point.)

Yeah, but 'pinning' dependencies is useful so that you can choose when you get those changes.

EDIT: you completely changed your comment. My original response is below the line, but I'll also respond to your new one above it.

I don't actually understand grammatically what you're asking for or saying in this comment. Rust, Cargo, and a bunch of Rust applications are packaged in Debian today, from Buster onwards.

I think what you're saying is that rustc head should be able to be built with the llvm that lives in Debian stable? That is a choice that could be made, I'm sure, but then you're talking about supporting five API-incompatible releases of LLVM. The folks from Debian aren't even asking for that level of compatibility, and it would be quite a bit of work, for unclear benefit.

--------------------------------------------

There are lots of demands, from lots of people. Managing a project requires prioritizing different demands of all of your different users.

> When will the problem mentioned in the article

The article talks about many more things than one single problem. Some range from easy, like the "we already do let you use stock llvm" I mentioned above, and some are difficult and take a long time, like "define a Rust ABI." The needs of packagers need to be balanced with the needs of other folks as well. "define a Rust ABI," specifically, for example, would help some packagers, but it may harm other users. It also may be something that's good to have, but we aren't quite ready for it yet.

A willingness to work together to solve issues, and to find solutions that help as many different kinds of folks as possible, is what matters here. We have had folks from other distros pitching in to help make things better for their distros, and I can't imagine we wouldn't accept the help of the OP either.

Nobody cares how secure my code is if it doesn't work.