Yawn. Another polemic by Drew DeVault. I mean, sure, in an ideal world, every package should be peer reviewed and all commits carefully scrutinized, tested, fuzzed, etc. The problem is, who is...
Yawn. Another polemic by Drew DeVault.
I mean, sure, in an ideal world, every package should be peer reviewed and all commits carefully scrutinized, tested, fuzzed, etc. The problem is, who is going to do that? On whose time/dime?
At some point you have to trust someone (see Reflections on Trusting Trust). DeVault says a Linux distribution package manager is a good candidate for that. This argument may be a bit obvious, but I'll make it anyway: a lot of stuff you need isn't actually packaged by any distribution -- this is especially apparent in machine learning stuff for me. It is unlikely that someone is going to thoroughly review and package and maintain forever every obscure piece of software you need for a one-off project, even if you ask nicely.
Yes, if you run untrusted code you have a problem if it turns out to be malicious. But there's really no way around that other than not using code from the internet -- even somewhat well-reviewed code could potentially contain hidden backdoors. Drew seems to be a fan of "I don't need dependencies, I write everything in C myself", but this post still seems disingenious.
Not a DeVault fan for the same reasons, but there’s a middle ground to be had. Look into Anaconda for Python ML work (if you haven’t already). Has screened versions of all the major packages,...
Not a DeVault fan for the same reasons, but there’s a middle ground to be had.
Look into Anaconda for Python ML work (if you haven’t already). Has screened versions of all the major packages, pinned on a rolling release. The “individual” version has very permissive licensing and you only pay if you want extraneous “enterprisey” features for a large team. They’ve really done some amazing work w.r.t. offering a secure dependency pipeline for data science work; can’t recommend it enough.
If you standardize on the latest version of Anaconda as a deployment target, and pin versions for any other dependencies pulled in via pip in your requirements.txt - you’re almost fully immune to run-of-the-mill supply chain injection IMO.
And to his credit, NPM is absolutely batshit insane from a security perspective and needs to die. There are truly serious concerns to be had within the industry. Distro package managers def ain’t the fix though.
There is a drew devault tag; I recommend using it and then just filtering out these articles. I only saw this one because it wasn't tagged originally, and I added the tag.
There is a drew devault tag; I recommend using it and then just filtering out these articles. I only saw this one because it wasn't tagged originally, and I added the tag.
You have a point, it adds a cost. I still think there should be a large organisation (Think KDE/GNOME/boost) which could do some vetting (You could even pay them to do that). It is not a bullet...
You have a point, it adds a cost.
I still think there should be a large organisation (Think KDE/GNOME/boost) which could do some vetting (You could even pay them to do that). It is not a bullet proof solution (If such a thing exists for security), but it's a good risk management strategy interm of cost-risk-reward.
Yes, but again, who pays for the effort? There will be some volunteers, but I'd bet that there's orders of magnitude more code than volunteers can feasibly review -- which likely leaves the...
Yes, but again, who pays for the effort? There will be some volunteers, but I'd bet that there's orders of magnitude more code than volunteers can feasibly review -- which likely leaves the smaller software packages that are most likely to be backdoored unreviewed.
That said, I think something like CREV has some promise. The idea is that everybody who reviews code (which, in theory, they have to do anyway to make sure there's no backdoor) can then vouch for that code, and you can choose to trust a given reviewer or organization. That way (again, in theory) the burden is spread among more shoulders.
I suspect there is nothing to be gained by commenting on this post, but I am doing it anyway: To complain about supply chain attacks while promoting a language without capability safety is...
I suspect there is nothing to be gained by commenting on this post, but I am doing it anyway:
To complain about supply chain attacks while promoting a language without capability safety is depressingly hypocritical.
Yawn. Another polemic by Drew DeVault.
I mean, sure, in an ideal world, every package should be peer reviewed and all commits carefully scrutinized, tested, fuzzed, etc. The problem is, who is going to do that? On whose time/dime?
At some point you have to trust someone (see Reflections on Trusting Trust). DeVault says a Linux distribution package manager is a good candidate for that. This argument may be a bit obvious, but I'll make it anyway: a lot of stuff you need isn't actually packaged by any distribution -- this is especially apparent in machine learning stuff for me. It is unlikely that someone is going to thoroughly review and package and maintain forever every obscure piece of software you need for a one-off project, even if you ask nicely.
Yes, if you run untrusted code you have a problem if it turns out to be malicious. But there's really no way around that other than not using code from the internet -- even somewhat well-reviewed code could potentially contain hidden backdoors. Drew seems to be a fan of "I don't need dependencies, I write everything in C myself", but this post still seems disingenious.
Not a DeVault fan for the same reasons, but there’s a middle ground to be had.
Look into Anaconda for Python ML work (if you haven’t already). Has screened versions of all the major packages, pinned on a rolling release. The “individual” version has very permissive licensing and you only pay if you want extraneous “enterprisey” features for a large team. They’ve really done some amazing work w.r.t. offering a secure dependency pipeline for data science work; can’t recommend it enough.
If you standardize on the latest version of Anaconda as a deployment target, and pin versions for any other dependencies pulled in via pip in your requirements.txt - you’re almost fully immune to run-of-the-mill supply chain injection IMO.
And to his credit, NPM is absolutely batshit insane from a security perspective and needs to die. There are truly serious concerns to be had within the industry. Distro package managers def ain’t the fix though.
E: typo fix.
There is a
drew devaulttag; I recommend using it and then just filtering out these articles. I only saw this one because it wasn't tagged originally, and I added the tag.Thanks, I will do that. Some of his older posts were interesting, but lately it's all inflammatory and non-helpful stuff.
You have a point, it adds a cost.
I still think there should be a large organisation (Think KDE/GNOME/boost) which could do some vetting (You could even pay them to do that). It is not a bullet proof solution (If such a thing exists for security), but it's a good risk management strategy interm of cost-risk-reward.
Yes, but again, who pays for the effort? There will be some volunteers, but I'd bet that there's orders of magnitude more code than volunteers can feasibly review -- which likely leaves the smaller software packages that are most likely to be backdoored unreviewed.
That said, I think something like CREV has some promise. The idea is that everybody who reviews code (which, in theory, they have to do anyway to make sure there's no backdoor) can then vouch for that code, and you can choose to trust a given reviewer or organization. That way (again, in theory) the burden is spread among more shoulders.
I suspect there is nothing to be gained by commenting on this post, but I am doing it anyway:
To complain about supply chain attacks while promoting a language without capability safety is depressingly hypocritical.
Go's minimal version selection is somewhat controversial, but I think it's an important advance in package management. Hopefully it will be copied.