When Will We Learn?
drewdevault.com
When Will We Learn?
1–10 of 17 posts
Re: When Will We Learn?
#2A good first step would be to have signatures and verification.
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.
Re: When Will We Learn?
#3> Why is this happening?
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.
Re: When Will We Learn?
#4No post body was provided.
Re: When Will We Learn?
#5I 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'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.
Re: When Will We Learn?
#6A good first step would be to have signatures and verification. 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.
Signatures by what participants, and at what stage(s) of the software development lifecycle?
Re: When Will We Learn?
#7The 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...
Re: When Will We Learn?
#8A good first step would be to have signatures and verification. 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.
Signatures by what participants, and at what stage(s) of the software development lifecycle?
By the person acting the release of a new version on the public repository (like any maintainer would do).
Re: When Will We Learn?
#9The 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...
This is the way. Unfortunately languages like Python will for implementation complexity/backward compatibility reasons never support something like this natively (unless with workarounds/hacks like compiling it to WebAssembly). It's time to phase out languages that don't. The only Python variants that made a foray into this are PyPy[0] and Monte[1]. It's important to make this sandboxing have only a small overhead, and make it work recursively, so external libraries can import partially untrusted external libraries themselves, thus hollowing out the attack surface at every node of the dependency tree.
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...
Re: When Will We Learn?
#10Earlier quoted context omitted.
Signatures by what participants, and at what stage(s) of the software development lifecycle?
By the person acting the release of a new version on the public repository (like any maintainer would do).
Thanks - agreed, release manager signatures are nice to have.
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.