When Will We Learn?
11–17 of 17 posts
Re: When Will We Learn?
#12I feel like there are more options between “npm” and “os package manager”. For the cargo example, I feel like namespaced packages could avoid the namesquatting typo issue. Also, I see no reason that verification or auditing can’t be built into these “overlay” package managers. I believe crev https://web.crev.dev/rust-reviews/ was trying to solve this in the Rust space.
Re: When Will We Learn?
#13I am sympathetic to Drew's view that packages require establishing a longer term trust relationships. That's literally what is happening when you use someone's package. You are trusting them.
So, I want the situation to change.However, there are some problems I see:
1. Developers are used to using their language of choice's solution for virtual environments (ex. go modules, node_modules, python venv, etc)
2. Instead of 1 relationship with the language package manager, you need N (where N is each platform you "officially" support)
3. Younger/newer packages aren't in native package managers yet.
4. Different apps want to use conflicting versions of libraries
For #1, VM's/Vagrant and Docker are a good answer. But many dev's only know their language's ecosystem and don't know shell well enough.
Personally, I think every dev needs to know their system well enough to be able to manage their environment and do things on the shell. But after working with more juniors, this is going to be a huge stumbling block.
For #2 seems unavoidable unless someone automates submitting to a bunch of package managers. And worse, many package managers do a lot of patching. Again I'm sympathetic to patches b/c many devs have a lot of bad practices. But this is a huge problem for devs, because it bogs down support channels with bugs tedious to track down and reproduce.
There's a kind of catch 22 in younger packages too, where they aren't in the repo's so no-one uses them. But no-one uses them, so it's not worth the effort to get into the repos.
For #4, this seems to be the perennial static vs. dynamic linking debate. Where newer languages and systems seem to be falling on the static side.
TL;DR: I live native package managers but there's too many problems to ignore. Until the dev experience is better, people are going to continue using language package managers.
Re: When Will We Learn?
#14The approach deno is taking is very interesting where all packages are sandboxed. I'd be interested to hear the author's thoughts on Deno's approach as a mitigation for supply chain attacks. I understand it won't stop all attacks but it would make them significantly harder. ref: https://medium.com/deno-the-complete-reference/sandboxing-in...
> “The approach deno is taking is very interesting where all packages are sandboxed.”
Can anyone clarify this?
My understanding is that packages are not sandboxed, but your entire Deno process is. Meaning that if one part of my app requires full read/write access then any package included in my app also gets it. Is that correct?
Such sandboxing is a secure default, and can help to limit the scope of a supply chain attack, sure, but this doesn’t make packages inherently more secure.
Per-package sandboxing would be cool, although I’m not sure how that would work.
Re: When Will We Learn?
#15I disagree on it being the OS maintainers job, for the reason of duplication of effort. Packaging every single package or library individually for every distro is a colossal waste of person power. But I agree that there should be a security review.
Re: When Will We Learn?
#16The approach deno is taking is very interesting where all packages are sandboxed. I'd be interested to hear the author's thoughts on Deno's approach as a mitigation for supply chain attacks. I understand it won't stop all attacks but it would make them significantly harder. ref: https://medium.com/deno-the-complete-reference/sandboxing-in...
> “The approach deno is taking is very interesting where all packages are sandboxed.” Can anyone clarify this? My understanding is that packages are not sandboxed, but your entire Deno process is. Meaning that if one part of my app requires full read/write access then any package included in my app also gets it. Is that correct? Such sandboxing is a secure default, and can help to limit the scope of a supply chain at…
> My understanding is that packages are not sandboxed, but your entire Deno process is. Meaning that if one part of my app requires full read/write access then any package included in my app also gets it. Is that correct?
Yes. There has been a discussion on per dependency permissions several times but the conclusions is that it would be difficult to implement and get right semantically. See https://github.com/denoland/deno/issues/171
Re: When Will We Learn?
#17I think Drew makes a good point about the fact that distributions implicitly perform a 'review' step for packages, but I'm not certain I agree with the idea that leaving all packaging to distributions is the best approach overall. Generally I think that the ability for individuals to upload packages and for those to be available immediately for consumption is an incredible benefit for developer productivity and pace.…
> I think Drew makes a good point about the fact that distributions implicitly perform a 'review' step for packages, but I'm not certain I agree with the idea that leaving all packaging to distributions is the best approach overall.
As was mentioned in this reddit comment on this very topic (https://www.reddit.com/r/linux/comments/uohnzg/when_will_we_...) package managers usually do not have a review process for updates:
> System package managers do not have a review process for package updates. Not for all packages, at least, and I would argue not for many packages.
> (...)
> The job of a package maintainer is to package software, not to perform security audits. They probably even lack the skills for performing security audits, because they are package maintainers, not security experts.
Now, you could make an argument that any filter, if not necessarily an audit or review cycle, just some time delay and having to convince a person that it's worth adding, is enough to add some measure of security. But equating it with "review" is just a misrepresentation of reality. And keep in mind that (To my understanding) distributions handle a vastly smaller set of packages than the tools Drew is proposing they replace. And I often hear about how they struggle to keep up with that. I doubt he doesn't know all this, so it's hard to read this as anything other than a bad faith argument to bash on things he doesn't like.