How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verification of package authenticity before installing built in.
RubyGems does have gem signing, but it's not widely used.
There's a proposal for a new "one button" approach using sigstore[0].
Other ecosystems are also looking at sigstore too, and a lot of us are cooperating in the OpenSSF Securing Software Repos WG [1]. Package signing is a regular topic of discussion and there are various efforts underway.
> RubyGems has had the ability to cryptographically sign gems since version 0.8.11. This signing works by using the gem cert command to create a key pair, and then packaging signing data inside the gem itself. The gem install command optionally lets you set a security policy, and you can verify the signing key for a gem before you install it.
> However, this method of securing gems is not widely used. It requires a number of manual steps on the part of the developer, and there is no well-established chain of trust for gem signing keys. Discussion of new signing models such as X509 and OpenPGP is going on in the rubygems-trust wiki, the RubyGems-Developers list and in IRC. The goal is to improve (or replace) the signing system so that it is easy for authors and transparent for users.
I tried it years ago and it was such a pain that I stopped, and I've a high tolerance for this kind of thing. I also found problems with certificate chaining that I've forgotten about (intentionally and gladly). Basically, it was like a lot of security stuff over the years, half-baked, badly implemented, with a poor UI and hence, doesn't get used.
Supply chain attacks are not uncommon. Package signing can protect against those:
1. Package source hacking. Say an attacker gets access to a package source's storage and inserts malware into popular packages. Now your project contains malware. Your package manager can detect tampering if the packages are signed.
2. Dependency confusion attacks. Say my project downloads packages from the public source as well as my company's private source. An attacker realizes my company has a private package named `private-foo` and uploads a malicious package with the same name to the public source. Now my projects contains malware as it occasionally downloads the malicious package instead of my company's private package. Your package manager can detect packages from an unexpected author if they are signed.
I can provide more examples if you'd like. None of these are hypothetical, all of them have happened already.
Just want to point out that bundler solves this problem (and many others). It pins gem versions in Gemfile.lock and it supports explicit source locations (like git repositories) for downloading gems.
In this setting, HTTPS provides integrity (the authoritative party is the package index, which can serve you anything.) It can't provide authenticity, which is the root of most of the more interesting attack vectors in packaging.
The Linux distros use OpenPGP/X.509 keys stored on HSMs for their archive security, and a set of per-maintainer keys that are used to verify changes to the archive. RubyGems/Cargo/etc could use something like that.
