When Will We Learn?
drewdevault.com
drewdevault.com
That's something that WebAssembly can't do well either, even if its boundary is secure. Creating a new sandbox means having to start a new instance "from the outside", the virtual machine doesn't have this capability built in.
This is the access security problem, there is another that almost all programming languages and virtual machines haven't even tried to solve, especially in a platform independent way: resource security. If an untrusted program cannot access anything but its own memory, but can still go in an infinite loop or allocate all memory and bring the whole system to a halt, the security architecture isn't as complete as it could (should) be.
Especially combined with process serialization[2], a system that implemented both of these security aspects correctly would make very interesting programs possible.
[0] https://doc.pypy.org/en/latest/sandbox.html [1] https://monte.readthedocs.io/en/latest/intro.html [2] https://stackless.readthedocs.io/en/2.7-slp/library/stackles...
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.
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
The author does not really explain the why, but gives a solution in that paragraph. I think the major reason why "overlay package managers" exist is simple: Time.
With current speed in design iterations, CI/CD, etc. time is the important factor. And as such a separate review process takes up that time (and binds considerable amounts of manpower).
But I agree: These package managers ran into a problem when they traded security for speed.
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'd also agree that review steps are important, so perhaps the defaults for application-side package managers should err more towards pinning to specific versions, rather than automatic updates (with the possible exception of security-related updates).
To me there are two common modes of software distribution:
- "Building-out" phase distribution: this is while applications and the libraries that they rely on are in active development -- they're 'leaf nodes' if we consider them as a dependency tree. This is where pace and the ability to iterate quickly is beneficial. Code and dependencies are likely not installed from the OS distribution, because that may not evolve quickly enough to support development.
- "Baking-in" phase distribution: the applications and libraries are maturing and have proven their worth in multiple production environments. Stable releases exist, and may have support offerings associated with them. This is where distribution-packaging shines; it makes trusted, well-tested software immediately and easily available to a very large number of users in a way that is reliable and doesn't introduce unnecessary support burdens on the distribution packaging teams.
I'd love to see more code review at various stages of software development; we typically do it during changeset development (pull requests), but I think that pre-release code review would make sense, and I also believe that post-release 'diff' code reviews would be valuable (what has changed between v1.1 and v1.2? do reviewers agree that it is safe, correct and documented?).
The growth areas I'd expect to see in software development careers are in maintenance and review. Perhaps not hugely exciting compared to feature development, but (again, my opinion only) more important for stability and overall software quality long-term.
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.
There's definitely room for overlay package managers (as he calls them), if only because they work _across_ systems mostly, and they have a higher release cadence, which is marginally useful for stable, proven apps releases, but is definitely helpful for development and experimentation.
The reason I ask is that I think it'd be nice if third parties could also voluntarily sign releases.
For example: the author of a library -- or one of their users -- could fund a security audit of a specific version, and then the auditors could sign to attest their findings (issue and severity count, perhaps) in a way that's visible to package users via the command-line and web.
It'd add useful information for people trying to select appropriately-secure code, and also help foster a marketplace for open source security code review.
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.