Debian Discusses Vendoring -- Again (lwn.net) 48
Jake Edge, writing at LWN: The problems with "vendoring" in packages -- bundling dependencies rather than getting them from other packages -- seems to crop up frequently these days. We looked at Debian's concerns about packaging Kubernetes and its myriad of Go dependencies back in October. A more recent discussion in that distribution's community looks at another famously dependency-heavy ecosystem: JavaScript libraries from the npm repository. Even C-based ecosystems are not immune to the problem, as we saw with iproute2 and libbpf back in November; the discussion of vendoring seems likely to recur over the coming years. Many application projects, particularly those written in languages like JavaScript, PHP, and Go, tend to have a rather large pile of dependencies. These projects typically simply download specific versions of the needed dependencies at build time. This works well for fast-moving projects using collections of fast-moving libraries and frameworks, but it works rather less well for traditional Linux distributions. So distribution projects have been trying to figure out how best to incorporate these types of applications.
This time around, Raphael Hertzog raised the issue with regard to the Greenbone Security Assistant (gsa), which provides a web front-end to the OpenVAS vulnerability scanner (which is now known as Greenbone Vulnerability Management or gvm). "the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has significant changes, in particular it now relies on yarn or npm from the node ecosystem to download all the node modules that it needs (and there are many of them, and there's no way that we will package them individually). The Debian policy forbids download during the build so we can't run the upstream build system as is."
Hertzog suggested three possible solutions: collecting all of the dependencies into the Debian source package (though there would be problems creating the copyright file), moving the package to the contrib repository and adding a post-install step to download the dependencies, or removing gsa from Debian entirely. He is working on updating gsa as part of his work on Kali Linux, which is a Debian derivative that is focused on penetration testing and security auditing. Kali Linux does not have the same restrictions on downloading during builds that Debian has, so the Kali gsa package can simply use the upstream build process. He would prefer to keep gsa in Debian, "but there's only so much busy-work that I'm willing to do to achieve this goal". He wondered if it made more sense for Debian to consider relaxing its requirements. But Jonas Smedegaard offered another possible approach: analyzing what packages are needed by gsa and then either using existing Debian packages for those dependencies or creating new ones for those that are not available. Hertzog was convinced that wouldn't be done, but Smedegaard said that the JavaScript team is already working on that process for multiple projects.
This time around, Raphael Hertzog raised the issue with regard to the Greenbone Security Assistant (gsa), which provides a web front-end to the OpenVAS vulnerability scanner (which is now known as Greenbone Vulnerability Management or gvm). "the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has significant changes, in particular it now relies on yarn or npm from the node ecosystem to download all the node modules that it needs (and there are many of them, and there's no way that we will package them individually). The Debian policy forbids download during the build so we can't run the upstream build system as is."
Hertzog suggested three possible solutions: collecting all of the dependencies into the Debian source package (though there would be problems creating the copyright file), moving the package to the contrib repository and adding a post-install step to download the dependencies, or removing gsa from Debian entirely. He is working on updating gsa as part of his work on Kali Linux, which is a Debian derivative that is focused on penetration testing and security auditing. Kali Linux does not have the same restrictions on downloading during builds that Debian has, so the Kali gsa package can simply use the upstream build process. He would prefer to keep gsa in Debian, "but there's only so much busy-work that I'm willing to do to achieve this goal". He wondered if it made more sense for Debian to consider relaxing its requirements. But Jonas Smedegaard offered another possible approach: analyzing what packages are needed by gsa and then either using existing Debian packages for those dependencies or creating new ones for those that are not available. Hertzog was convinced that wouldn't be done, but Smedegaard said that the JavaScript team is already working on that process for multiple projects.
Re: (Score:3)
And Windows has long had to contend with the same problem, to the point where it has to maintain separate containers/folders for all the various dependencies that inevitably come with different software requiring different versions of the dependencies. There's no right answer to this problem, only ones that create more or less clutter. While the nice thing about open source software is often you can simply make relatively small changes and recompile, I've often simply compiled libraries statically with the
Re: (Score:2, Insightful)
Storage is cheap so fat binaries don't scare me and shouldn't scare anyone else. The kinds of systems that have a storage constraint are also going to be fairly dedicated in purpose and wont wont have a lot of extra software loaded anyways.
So for those reasons I think that static linking is usually the best solution. Dependency hell can be pretty awful and should be avoided. Dependency death, where different repo servers go down overtime and aren't mirrored is also a problem in the FOSS world. There is a lo
Re: (Score:3)
Both memory and storage have to be cheap at the same time for that approach to make sense. You don't only have to store the libraries on disk, you have to load them into memory as well.
Sometimes it's worth it to have static binaries, or at least included libraries. But that's generally only when a program is already going to use a whole lot of memory. It's unsatisfactory for anything else.
Re: (Score:2)
You don't have to load everything into memory at runtime. I know that's a common thing to do now a days and is a lazy habit brought on by the notion that "the user can always add more".
Local NPM Registry (Score:3)
Umm... have these folks never heard of a Local NPM registry [npmjs.com]? There are literally a dozen different solutions to choose from here. Do they think commercial vendors download all their NPM dependencies from the internet every time they build???
Re:Local NPM Registry (Score:4, Insightful)
For a long time, Debian has been striving for Reproducible Builds [lwn.net], where building a source package produces the same output every time. Even with a local NPM registry, it would be nearly impossible to keep track of what was in the registry at the time of doing the build unless that content is actually in the source package itself.
Re: Local NPM Registry (Score:2)
It shouldn't be hard at all, because every package should be digitally signed and it should never change. If it changes, you have bigger security related problems.
Re: (Score:1)
Debian already maintains a package management infrastructure.
Maybe the solution is to lean even harder into this concept with something like a fake_npm package that has an npm that just wraps dpkg, checks to see if the deb containing the requested package is present. If it isn't it could error out telling the user that the package they are building is missing a build dependency on "whatever". This way the build process doesn't need to download anything, but it acts the same to the build commands.
Then ideal
Surprised there's no "alien"/"debhelper" approach. (Score:3)
Many, many years ago I had a little fun making an extension to automatically convert CPAN perl code projects to an installable package. There was adequate meta-data in CPAN to do a pretty good job at it. The current package managers for the java/js/c# generally astound me with the amount of cruft in the packaging system... I wouldn't say it would surprise me if they were missing some information to make that possible, but I'd suspect they should have all the bases covered there.
Re: (Score:2)
Re: (Score:2)
So crusty it's likely useless at this point. It looks like more proficient coders subsequently took the same route with dh-make-perl [metacpan.org].
Re: (Score:1)
gem fpm can do these sorts of conversions:
https://fpm.readthedocs.io/en/latest/
Security and reliability (Score:5, Insightful)
Seems to me all too many things, particularly websites, fetch things from third parties on the fly, making them susceptible to compromise by things they have given up control over, whether it be security or gratuitous changes. Keeping the things you know work local will make things much more stable.
Re: (Score:1)
And no, the OS vendor doesn't have to look at any source code. They can demand signed packages traceable to an identified individual (and yes, you can identify people, like PayPal does for sellers for example), that's all.
Re: (Score:3)
Then they could 1) not provide security fixes and 2) nobody could trust the software to not include malware (a problem we see in other app stores)
I like what they are doing.
Re: (Score:2)
Re: (Score:2)
1) would not work for most open-source software
2) signed software does not guarantee that as software secure.
Re: (Score:2)
Re: (Score:2)
1) Only if you define everything as crap which has no security support from a professional entity. There is a lot of useful open-source software which is developed by hobbyist, is not maintained anymore etc. Still Debian can provide meaningful security support which it could not for binaries.
2) Being able to identify the author does not make software secure.
Re: (Score:2)
2) It does make it non-malicious though, because releasing malicious code with your real name on it could make for some very interesting lawsuits. It's why the App Store has hosted just a d
Re: (Score:2)
1) This is not how open source works. In 90% of open cases developers made the software available because they could but they do not have the resources to maintain it forever or provide the security support. The open source community takes over these tasks and the distributions are part of this community.
2) It is some small deterrent for putting malicious code into the app store, but no guarantee for safe software. I can't remember Debian every distributing malware. So the only one doing it correctly are L
Re: (Score:2)
Re: (Score:2)
1) In practice, security support for open source works much better than for most commercial software or app stores. So what works better in practice is the more responsible thing to do in my opinion.
2) npm is not the Debian package manager. If you install npm using Debian to install other software using npm, then this is not really related to our discussion.
Re: (Score:3)
So Debian (and Fedora, and probably others) are a bit focused on open source specifically. They want to provide users of their distributions comfort that unless they opt specifically in, that their OS will give the end-user source code.
This is not about trust (though that is very nice) and its more about the end user being able to modify any component, or perhaps just learn, or figure out why something isn't working when the component documentation fails to get them an answer.
Now there are other distribut
Re:Fetishization of source code. (Score:4, Insightful)
In normal operating systems, the application author releases a self-contained package (exe, msi, dmg, or apk), which supports operating system versions X and higher, and that's it. The OS vendor doesn't care if the application package gets created using source code compilation, assembly hand-hacking, or a magnetized needle and a steady hand.
In the case of Linux and BSDs, the OS vendor *becomes* the author of the pre-installed user apps. They're essentially forking the source repositories, building them, and redistributing them. One advantage of this is that it's harder for apps to become abandonware due to only the original developer knowing how to actually build it. They also don't have to wait around for the author to update if they port to a new architecture or make backwards-incompatible changes to the OS.
Another advantage is that it is very explicit what exactly is getting installed on user's systems. (Even though npm and similar automagical download systems for Go, Rust, etc are working to dilute this advantage through obscurity, complexity and churn, which I guess was the whole reason for this article).
Also, if Microsoft or Apple did something similar to Debian repositories and had so much control over how apps are compiled and installed, everyone would lose their minds.
If Microsoft and Apple published the source code for their OSes and made them freely redistributable and modifiable, nobody would care what they bundled them with.
Re: (Score:2)
As I said in a previous comment, there was no sane decision-making process involved. "Dependencies" as implemented by deb and rpm allow developer
Re: (Score:2)
Obviously, you can't possibly imagine that anybody could have a use case different than yours.
You're happy down at Best Buy buying whatever closed source spyware gadgets they have on offer. You're satisfied that your only recourse for any problem is "take it or leave it".
Well, good for you.
Re: (Score:2)
Re: Fetishization of source code. (Score:5, Informative)
"From the view of the outsider, all this fetishization of the source code happening by the Debian people seems ridiculous."
That's because you care more about convenience than freedom. Use a different distro.
Re: (Score:2)
Re: (Score:2)
Did you mean to reply to the same post I replied to?
FWIW/FTR I think E2E is important.
Re: (Score:2)
Re: (Score:1)
Sort of the point of Linux and open source is to ensure that end users have the source code for what they're running.
Re: (Score:2)
Re: (Score:2)
In normal operating systems, the application author releases a self-contained package (exe, msi, dmg, or apk), which supports operating system versions X and higher, and that's it
BTW, that is precisely what you have with .deb, .rpm, etc. For example, debian won't include google chrome. Somehow, you can still install google chrome. apt and yum are not lock-in, they are value-add and you can ignore them at will.
Also, if Microsoft or Apple did something similar to Debian repositories and had so much control over how apps are compiled and installed, everyone would lose their minds.
MS and Apple both have App stores, which are the closest analog to apt/yum. Except apt and yum are extensible so that you can add sources that don't come from your OS vendor. So yes, vendors would lose their mind at finally being able to be auto-updated by the OS by registerin
Re: (Score:2)
Re: (Score:2)
They do not demand you have dependencies, if you so desire you can have, say, your static application/go/whatever as an rpm/deb with no dependencies. It is a *feature* to allow you to participate in the broader ecosystem and intelligently pull in parts, if you want to. It is highly recommended.
allow developers to be lazy and not think about dependency management, dependency integration testing, and testing against multiple versions of the OS at the authoring phase.
This is absolutely not the 'lazy' way. The lazy way is static/bundled packages and ignoring dependencies. To do dependencies, you have to build per OS and do testing. To build a package for a distribution is *more* de
Re: (Score:2)
Debian is supposed to be stable (Score:2)
It's not a cutting edge distro. It's not supposed to be fast moving or on the cutting edge of development. If you want to package your latest and greatest shiny then that's exactly what containers are for. For users who want all their packages like this, don't use Debian.
Re: (Score:1)
The problem isn't with keeping the absolute latest version of the package in there. The problem is these multiple dependency sources are preventing packages from ever getting in there. and as more and more software is built on the massive dependency frameworks like electron debian needs to come up with a a solution so they can have even an older version of some programs like say electron.
It's the corporate / Windows mindset. (Score:4, Insightful)
Of seeing software as applications. Monolithic fortresses that do not cooperate and do not share. All because they got the business model wrong (Development is a service, not software a "property"), and it now depends on not sharing with others so that blackmailing works.
For example, it is ridiculous that I can't use the Photoshop tools in Word, or vice versa. If the data format fits, it should work, no questions asked.
This is one reason for Unix's "do one thing and do it right" and "everyting is a file".
This is also why frameworks are part of that cancer.
And container formats like Snap. (Dependency hell is a solved problem, boys and girls. Portage has no problem installing more than one version of a library in parallel and having software use the right version.)
And deveopers that grew up in a world like that niw pour into open source software, thinking they can take their 'culture' with them.
Just look at how Steam is implemented. There is no Linux version of Steam. It ignores pretty much every rule there is. File system, place of files, package manager, hell it doesn't even use Linux facilities but runs on Wine. It is still 100% Windows. Grafted onto Linux like a truck onto a human cheek.
I have hope that this will change though, even thougj you can't teach them. IFF we stay stong in the face of their clueless cockiness (Yes, hello Poettering!), and they get older and hurt themselves with their bad choices a time or two, and learn from it by themselves.
As a wise man once said: Those who do not understand Unix, are doomed to re-invent it. Badly. In two or three decades. After much bickering and arrogant cocky behavior typical for the youth. ... ;)
Re: (Score:1)
Versioning (Score:2)
In my opinion, part of the problem is that some modern developers seem to have dropped the concept of release. There is no more versioning, you are advised to pick latest code from github.
That makes it a nightmare to integrate software in package systems, since you never know if today's latest will fit correctly for different components that depends on it.
Great summary (Score:1)
I'm impressed at what a comprehensive and comprehensible summary was provided for this article.
Containerize dpkg? (Score:2)
It sounds like it's time to think about dpkg having overlays that can exist inside containers - OpenVZ or whatever. And then some automagic packaging tools to build a hairy mess out of npm dependencies or whatever. Apt would need to know how to descend and manage the tree. Post-Bullseye, at least.
What we don't want is to have application vendors be responsible for security updates on all of their libraries. It just doesn't work. Like 99% of the time that strategy fails.
Apologies for the very few consci
many developers stink up the web, too (Score:4, Insightful)
I used to argue that all web designers and implementers should live at the end of 9600 (later, 56k) pipe from their test systems. Most of their users had to do that at the time, and it would have made it obvious that their cruft was making life miserable for the users.
These days, far to many of the clowns do not take into account real-world deployment of their "northbound end of a southbound mule" product. Nothing should be acceptable for a release (development branch, fine) unless it can be delivered as an appropriate package on at least Red Hat and Debian. Doesn't help us BSD folks, but it would be a start.