Forem: Tieg Zaharia

The current state of package invalidation support across package managers

Tieg Zaharia — Thu, 01 Apr 2021 16:27:52 +0000

Deprecate, retract, unpublish, abandon, yank, orphan, archive...

What do all these have in common? Well, they’re different terms for what I’ll call “package invalidation.” Here’s what I mean by package invalidation:

Package invalidation (n): the indication that an open source maintainer doesn’t want you to use their package or release(s).

Do all package managers support invalidation?

Some programming language ecosystems have built-in tooling for invalidation, and some purposely don’t allow it, but one thing certainly holds true: none are the same.

You can view package invalidation support in two dimensions:

Package-level vs. release-level: either the full package is invalidated, or just specific releases (i.e. versions).
Deletion vs. deprecation: either the package is totally unavailable/gone/404’ed, or it is just marked as deprecated (i.e. a soft warning to not use the package).

Note that “code deprecation” is a separate topic.

Why would you invalidate a package?

Maintainers will invalidate their packages for a range of reasons:

the maintainers are stepping away
it’s vulnerable to a bug or has malicious code
it’s being renamed or moved
there’s a better/faster alternative
secrets were accidentally published
it has a licensing issue

Are there problems with package invalidation support?

Yes 😬 ... package invalidation is a thorny and overlooked topic:

Firstly, every ecosystem implements invalidation differently. For example, the Maven package ecosystem for Java doesn’t allow removal of packages because it considers its package index immutable. Clojure, though—a language on the Java platform—follows suit but will make exceptions for security’s sake and is considering a more nuanced approach. When you’re in a polyglot environment, recalling the differences among ecosystems will be arduous.

Another problem is that it’s often difficult to know when a package/release that you use is invalidated, unless it’s outright deleted (which might be too late for your CI builds). For example, even though RubyGems allows the removal of a specific release by the maintainer, you may never know if you are using cached versions of that release.

Lastly, a big problem we found is that maintainers often don’t use the built-in tooling. Sometimes package invalidation is just a note in the README (maybe a “DEPRECATED” note or a badge from unmaintained.tech). This makes it even trickier to be warned against using a package.

Matrix of support

Because this subject can be so complex and confusing, we have compiled a matrix of invalidation support for you to use as reference.

Language	Package index	Package deletion	Release deletion	Package deprecation	Release deprecation	Terminology
Haskell	hackage. haskell.org	⛔️	⛔️	✅	⛔️	“deprecate”
Rust	crates.io	⛔️	⛔️	⛔️	✅	“yank”
Clojure	clojars.org	⛔️	✅	⛔️	⛔️	“delete”
Objective-C	cocoapods.org	⛔️	✅	✅	⛔️	“delete” & “deprecate”
PHP	packagist.org	✅	⛔	✅	⛔	“delete“ & “abandon”
Python	anaconda.org	✅	✅	⛔️	⛔️	“delete”
Perl	www.cpan.org	✅	✅	⛔️	✅	“delete” & “deprecate”
Go	pkg.go.dev	⛔️	⛔️	⛔️	✅	“retract”
Java	search. maven.org, etc	⛔️	⛔️	⛔️	⛔️
Erlang	hex.pm	⛔️	⛔️	⛔️	✅	“retire”
JS	www.npmjs.com	✅	✅	⛔️	✅	“unpublish” & “deprecate”
.NET	nuget.org	⛔️	⛔️	⛔️	✅	“deprecate”
Python	pypi.org	✅	⛔️	⛔️	✅	“delete” & “yank”
R	cran.r-project.org	✅	⛔️	✅	⛔️	“archive” & “orphan”
Ruby	rubygems.org	⛔️	✅	⛔️	⛔️	“yank”
Swift	swiftpackage registry.com	⛔️	⛔️	⛔️	⛔️

How the Tidelift Subscription can help

It can be very tricky to learn about deprecated packages and to navigate each ecosystem’s support, even if you’re paying attention. So how would you be alerted to and/or act upon an invalidated package?

Tidelift catalogs can help: catalogs provide a birds-eye view of all the open source packages that your organization is using. Catalogs have a “Releases are actively maintained” standard that you can enable and enforce.

When enabled, it will let you know when a deprecated package is in use and lets you block it from all your projects. We pull this data via the official tooling from each ecosystem as best we can, so you don’t have to worry about all these details.

And by paying for the Tidelift Subscription, you’re also paying the maintainers. The maintainers know best whether a package has been invalidated, and we work closely with the maintainers to bring that information directly to you via the Tidelift Subscription. Curious how that works? You can watch a short demo, or, better yet, schedule a custom demo and one of our team members will show you how Tidelift catalogs work.

The state of package signing across package managers

Tieg Zaharia — Thu, 11 Jun 2020 14:49:58 +0000

Recently I looked at the state of 2FA support across package managers. 2FA adds a layer of security by requiring two sources of authentication from maintainers when publishing packages. This helps open source communities avoid supply-chain attacks by protecting packages from their author to their repository.

2FA is great, but hinges upon the package repository being secure, and isn’t an end-to-end verification that a package came from its maintainer.

But there’s another way that isn’t as dependent upon the package repository: cryptographic signing of packages. Let’s take a look at which platforms support package signing.

But first, what is package signing?

Package signing is the act of an open source package (repo, binary, recipe, etc.) being cryptographically signed with a private key so that downstream users can verify the package with a public key.

Across language ecosystems, there are generally two types of package signing:

Signed-by-repository: the repository signs uploaded packages, and users verify them after downloading.
Signed-by-author: the author signs packages before uploading them to a repository, and users verify them after downloading from the repository. This is an end-to-end guard to ensure the package was uploaded by its maintainers.

Why is package signing useful?

Whether you’re setting up a new codebase on your developer machine or deploying a webapp to your servers, you’re probably downloading dozens—or hundreds—of open source packages. It’s impractical to comb through every line of code to make sure the package you received was not tampered with. Package signing offers a way to say I trust this maintainer and I am guaranteed that this code was uploaded by them.

Which programming language package managers support package signing?

Let’s try to classify what each package manager does currently:

Author-signing:

Nuget: as of nuget cli 4.6.0 (March 2018), packages can be signed with certificates from a list of trusted Certificate Authorities, and verified against those CAs or a specific set of key fingerprints. Nuget also supports repository-signing.
Maven/Gradle/Ant: all packages uploaded to Maven Central are required to be PGP-signed, and all three package managers have tooling to sign and verify.
Rubygems: authors can sign packages using SSL certificates based on RSA keys. Verification offers several levels of signature checks.

Caveat: supports Certificate Authorities but doesn’t make any CA recommendations for the ecosystem, so there’s no central CA.
Usage: we found that, as of March 2020, only 1.4% (2,216 of 157,640 gems) of latest-version gems on Rubygems.org were signed.

Repository-signing:

npm: npm signs packages with its own PGP key, which is publicized on Keybase.
- Caveat: although npm doesn’t have native author-signing, there is some 3rd-party tooling available via the pkgsign library.
- More: some interesting discussions about signing have happened on node-forward, and npm.

In progress:

Pypi: Python 2.5 added support for author-signing with GPG (via python setup.py --sign upload), but there is no built-in support to verify those signatures yet.

Caveat: there are active discussions and PEPs around signing packages—PEP 458 for repository-signing and PEP 480 for author-signing—using The Update Framework.

Wordpress: discussion of signing happened here, and signing of Wordpress itself was added here. As of 5.2, WordPress updates are now signed, but plugins and themes are still unsigned.

Caveat: there’s an open discussion about implementing author-signing via a PKI called Gossamer.

Partial or no signing:

Go Modules (Go): as of Go 1.13, Go Modules verifies downloaded packages (which are usually git repos) against a checksum database.
Composer (PHP): there have been discussions of built in signing/verification here.
Cargo (Rust): crates are hosted on GitHub*, and the Rust community has discussed package signing here, here and here.
CPAN (Perl): no built-in support, but author-signing is available via 3rd party package manager pp (or the underlying cpansign cli)
Carthage (Cocoa): packages are hosted on GitHub*, GitLab**, Bitbucket***, etc
Julia Pkg (Julia): packages are hosted on GitHub*, GitLab**, Bitbucket***, and registered with the Julia Package Registry on github.
Bower (JS): packages are hosted on GitHub*, GitLab**, Bitbucket***, etc
PDK (Puppet)
Meteor (Meteor)
Cabal (Haskell)
Mix (Erlang)
R (R)

Does package signing matter?

If you read through the discussions linked to above, package signing is indeed a lofty goal and challenging to get right. So is it worth it, and could it prevent any classes of exploits? You can find some examples of supply chain attacks from the past decade documented here and here. Those lists contain some examples of repository account takeovers and other exploits that could be mitigated using package signing.