dart-lang / dart-lang/pub-dev

Package signing

Open
#5,750 10 comments 6 reactions 0 assignees View on GitHub
Type: enhancement
Dominant language
Dart
Stars
944
Forks
184
Avg merge
1d 15h
Merged PRs (30d)
12

Description

Note sure if this should be reported here or for the pub client, it probably affects both. After seeing the [latest instance](https://twitter.com/lrvick/status/1523774962909298690) of taking over NPM packages by stealing e-mail addresses (which I believe would also be possible on pub.dev), I'm wondering if pub should optionally support signed releases for security-conscious package maintainers and users.

My idea is essentially the following:

- Add an option `--sign` to `pub lish` that causes the uploaded package to be signed. E.g. `pub lish --sign ` for which pub could shell out to something like `gpg --armor --local-user --detach-sig package.tar.gz` to get a `package.tar.gz.asc` which would also be uploaded to the package repository.
- Verifying signatures should probably happen when `pub` downloads packages. But as a sanity check without security benefits, pub.dev could fetch the key from a signature (for reference, Maven central considers [these keyservers](https://central.sonatype.org/publish/requirements/gpg/#distributing-your-public-key)) and perhaps check whether the user id of the key matches the publisher.
- Then there could either be an environment variable or perhaps a `--verify` flag to `pub get` and `pub upgrade` to handle signatures. I'm thinking of different levels that might be possible:
1. Ignore signatures (the default).
2. Verify signatures if there are any, print warnings for failed checks / unknown keys.
3. Verify signatures if there are any, refuse to download package versions that don't have a signature or can't be verified.
- Maybe there could be a small bump to a package score for signing or a tag for signed packages in the search results page to encourage signing, but it would be optional for both publishers and users.
- Perhaps pub.dev should enforce new versions being signed if a previous version of a package was signed. Or there could be an option in the admin page of the package to enforce signed releases.

I think an approach like that has some advantages:

- If they want to, users can be reasonably sure that neither an attacker or pub.dev added or modified a package.
- pub.dev only needs to host signatures, the creation and verification of signatures happens in the pub client.
- It is entirely optional and doesn't impact users who don't care about this.

There are some downsides of this though:

- This would only work if dependencies of a package are signed as well, so there's a network effect and it's probably not too useful initially.
- It's questionable how many end users are actually interested in this.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.