Document Secure Download Verification (Cryptographic Signatures, PGP, GPG)

[maltfield]

This ticket is a request to:

1. Upload the rclone Release-Signing PGP key onto multiple domains,
2. Document how a user can verify the rclone Release-Signing PGP key from multiple domains out-of-band when importing the key to their keyring for the first time (TOFU), and
3. Document how a user can verify the authenticity of an rclone release after download and before installing it

Why?

It's possible for a very powerful adversary to comprimise your release infrastructure (or the infrastructure between the server and the client) and get a new rclone user to download a malicious version of the release, signature, and the release signing key -- but it's exponentially more difficult for them to comprimise multiple distinct domains.

Here's a great list of historically relevant cases where this has already happened to other open-source projects:

• https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

This risk can nearly be completely eliminated by uploading your key to as many distinct domains as possible.

Part One: Making key available out-of-band

GitHub

Please upload your public key to some connoncial URL of one of your github repos. I'd suggest using a KEYS file in the root of your rclone repo, per the Apache standard

• https://github.com/rclone/rclone/blob/master/KEYS
• https://infra.apache.org/release-signing#keys-policy

rclone.org

Please upload your public key to some permalink on your website. /KEYS or /key.txt would be a reasonable location.

• https://rclone.org/KEYS
• https://rclone.org/key.txt
• https://megous.com/key.txt

craig-wood.com

• https://www.craig-wood.com/nick/KEYS
• https://www.craig-wood.com/nick/key.txt

SKS Keyservers

Please upload your key to an SKS keyserver. For example:

• https://keyserver.ubuntu.com/

https://keys.openpgp.org/

keys.openpgp.org is a newer keyserver that doesn't sync with the others, and it strips UIDs and signatures by default for privacy and to resist certificate spamming attacks

Please upload your PGP key to keys.openpgp.org

• https://keys.openpgp.org/

Twitter

Please add your public keys' full fingerprint to the account description of your twitter account

• https://twitter.com/njcw

reddit

Please add your public keys' full fingerprint to the sidebar of your subreddit:

• https://old.reddit.com/r/rclone/

Other domains

I do recommend adding your key to as many other domains as possible, including:

1. Mastodon
2. Your official keybase.io account
3. Any domains you own
4. DNS TXT Record
5. Something else?

The more domains you upload it to, the better.

Part Two & Three: Documenting it

After uploading your public key and/or full fingerprint to as many distinct domains as possible, please update the project's documentation to enumerate all of these locations and write a paragraph describing how the user can mitigate the risk of compromised infrastructure by cross-checking the integrity of the key across multiple domains.

• https://rclone.org/downloads/
• https://rclone.org/install/

The above pages should also document how a user can use GPG to verify that a given release is cryptographically authentic after downloading it.

[maltfield]

See also:

• Cannot find GPG key that signs the checksums #5764
• PGP signed checksums for rclone precompiled binaries #1449

[ncw]

Thank you for your comments.

You can find my key on

• https://keyserver.ubuntu.com/ (I was under the obviously mistaken belief that the keyservers talked to each other!)
• https://www.craig-wood.com/nick/pub/pgp-key.txt (that is an old copy with fewer signatures)

I take your point about uploading it to as many possible places as possible and I need to update the key on my website and make it easier to find.

Once thing I was considering was having a separate key for the rclone releases. For a few years at least I'd need to sign the sums with both keys (which I think you can do with gpg).

Having a separate key would mean that I could pass on the release role to someone else if necessary.

Your thoughts on that would be appreciated.

[maltfield]

Thanks for the quick reply :)

Once thing I was considering was having a separate key for the rclone releases.

Having a separate key would mean that I could pass on the release role to someone else if necessary.

I think it would be a good idea to mint a key that's specific to signing releases from the rclone project. If you do this, please follow best-practices by minting a key that is:

1. RSA
2. 4096-bit
3. signed by your old key

For a few years at least I'd need to sign the sums with both keys (which I think you can do with gpg).

That would be a good idea, but I think it's optional. What is required when changing keys is to write a Key Transition Statement that indicates you've changed keys, says why you've changed keys, and lists the fingerprint of the old and the new keys. Then you'd sign the statement by both the old key and the new key. And publish it in as many places as possible (GitHub, rclone.org, official forums, twitter, etc).

Ideally you'd give a transition period of 1-6 months where (after you publish the Key Transition Statement), releases are signed by both keys. After that, just sign with your new release key.

Riseup has a good guide/template on Key Transition Statements:

• https://riseup.net/en/security/message-security/openpgp/key-transition

I also recommend reading their OpenPGP Best Practices Guide

• https://riseup.net/en/gpg-best-practices

Here's an example Key Transition Statement:

• https://tech.michaelaltfield.net/2017/10/01/gpg-key-transition-statement/

[maltfield]

Here's an example of a documentation page that enumerates all the places that a user can download (cross-check) a project's release signing key on TOFU

• https://docs.featherwallet.org/guides/release-signing-key

[ncw]

Thanks - great links - will study further.

The feature rclone selfupdate uses the existing public key (it is embedded in the binary) so I'd need to make something that was backwards compatible for a while - that is why I was thinking of signing it twice.

Great idea about signing the new key with the old - I should definitely do that with my other gpg key which I use for signing gpg commits on github.

I noticed just now you can get keys from GitHub too

• https://github.com/ncw.gpg

[maltfield]

@ncw it's actually not possible for gpg users to use your key to verify rclone releases, for the past 8 years.

user@disp2914:~$ gpg --import
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i

mQCNAir+llYAAAEEAOma/TtngrpJ+Qabj9JNL/+SMqIGcXPRwHMs9UrvvvoPpWQf
24utY1OaGiCaWvzOpGukmk3lHfzNGbn46QMFBIKlSsycuwT71adY6upwexixjZQZ
Vh0dkp0PDi0w4xIY21amsI3MZ2lcGoAO9pycc3NJEe50q7/TfhG4/9vYVhqvAAUR
tCZOaWNrIENyYWlnLVdvb2QgPG5jd0BheGlzLmRlbW9uLmNvLnVrPrQlTmljayBD
cmFpZy1Xb29kIDxuaWNrQGNyYWlnLXdvb2QuY29tPg==
=QnjI
-----END PGP PUBLIC KEY BLOCK-----

gpg: Total number processed: 1
gpg:     skipped PGP-2 keys: 1
user@disp2914:~$ 

Note the above output skipped PGP-2 keys is due to the fact that GnuPG software releases since Nov 2014 don't support older, unsafe keys. The below quote is taken from the release notes of GnuPG 2.1 (released 2014-11-06):

• https://gnupg.org/faq/whats-new-in-2.1.html#nopgp2

Removal of PGP-2 support

Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits.

With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message.

There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key.

[maltfield]

Thanks - great links - will study further.

Many large organizations sign their releases with PGP. Here's some other best-practices guides that they've written which you may want to skim.

1. https://infra.apache.org/release-signing
2. https://docs.opendev.org/opendev/system-config/latest/signing.html
3. https://wiki.debian.org/Subkeys
   a. SHA256SUMS.sign https://www.debian.org/CD/verify
4. https://riseup.net/en/security/message-security/openpgp/best-practices

[ncw]

@ncw it's actually not possible for gpg users to use your key to verify rclone releases, for the past 8 years.

I've updated that key - can you check it again for me please? https://www.craig-wood.com/nick/pub/pgp-key.txt

Its the same key just format converted. This seems to work when I try it.

I've also uploaded to

• keyserver.ubuntu.com
• keys.openpgp.org

[maltfield]

I was able to download the file linked-to above and import it into my GPG keyring on Debian 11. In fact, the file's public key block contains two public keys

user@disp8241:~$ wget https://www.craig-wood.com/nick/pub/pgp-key.txt
--2023-09-03 08:17:55--  https://www.craig-wood.com/nick/pub/pgp-key.txt
Resolving www.craig-wood.com (www.craig-wood.com)... 89.200.136.113
Connecting to www.craig-wood.com (www.craig-wood.com)|89.200.136.113|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6632 (6.5K) [text/plain]
Saving to: ‘pgp-key.txt’

pgp-key.txt         100%[===================>]   6.48K  --.-KB/s    in 0s      

2023-09-03 08:17:57 (576 MB/s) - ‘pgp-key.txt’ saved [6632/6632]

user@disp8241:~$

user@disp8241:~$ gpg --import pgp-key.txt
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: key 93935E02FF3B54FA: 2 signatures not checked due to missing keys
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 93935E02FF3B54FA: public key "Nick Craig-Wood <nick@craig-wood.com>" imported
gpg: key CB0DBEBC5F32C81D: public key "Nick Craig-Wood <nick@craig-wood.com>" imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
user@disp8241:~$

user@disp8241:~$ gpg --list-keys nick@craig-wood.com
pub   dsa1024 2001-09-27 [SCA]
      FBF737ECE9F8AB18604BD2AC93935E02FF3B54FA
uid           [ unknown] Nick Craig-Wood <nick@craig-wood.com>
sub   elg2048 2001-09-27 [E]

pub   rsa4096 2022-09-16 [SC]
      E3B358DC858FB307F48170B9CB0DBEBC5F32C81D
uid           [ unknown] Nick Craig-Wood <nick@craig-wood.com>
sub   rsa4096 2022-09-16 [E]

user@disp8241:~$

The first key FBF737ECE9F8AB18604BD2AC93935E02FF3B54FA was minted in 2001 and is DSA 1024-bits -- that's very old & bad.

The new key E3B358DC858FB307F48170B9CB0DBEBC5F32C81D was minted in 2022 and complies with the best-practice RSA 4096-bit :)

[ncw]

I'm going to upload a doc which describes the release signing process and how to get and verify the keys as part of the v1.64 release. You'll find links on the downloads and install pages.

If you think it needs any changes I'd be grateful for feedback.

Thank you for your very informative comments above.

[maltfield]

@ncw Excellent work! Thank you so much for prioritizing this <3

For others, the new documentation can be found here:

• https://rclone.org/release_signing/

I have one nitpick: currently it's not clear exactly where to download the (signed) hash files.

In the release directory you will see the release files and some files called MD5SUMS, SHA1SUMS and SHA256SUMS.

I see in the commands that follow a URL is given, but a user won't be able to use that command unless they already have rclone installed -- a chicken & egg problem for new users.

Perhaps you can make release directory in the above text a hyperlink to https://downloads.rclone.org/ ?

[ncw]

I see in the commands that follow a URL is given, but a user won't be able to use that command unless they already have rclone installed -- a chicken & egg problem for new users.

Those rclone commands wlll translate very easily to curl commands. We could show both?

Perhaps you can make release directory in the above text a hyperlink to https://downloads.rclone.org/ ?

Good idea.

Do you want to send a PR to adjust any / all of that?

This is the master file https://github.com/rclone/rclone/blob/master/docs/content/release_signing.md (nothing else needs editing). You can even edit in the browser - click the pencil icon!

[maltfield]

@ncw PR is submitted #7440