Package signing
- 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
Assessment
This issue has not been assessed yet.