Should we share the public key for checking signing in the git repository?

Question

In the book Pro Git, Tagging Your Releases:

It shows a way to collect the public key into a blob in git，so users who sync it can add that public key and to verify the signed tag.

Is this way actually safe? Someone can change the public key blob and redo the signing.I think we should get the public key from a separate and authorized way, right?

The commands in the book are pasted as following:

$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon "
1024-bit DSA key, ID F721C45A, created 2009-02-09

$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid                  Scott Chacon 
sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]

$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92

$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92

$ git show maintainer-pgp-pub | gpg --import

user_695343 · Answer

There's nothing wrong at sharing your signing key, even though it of course should not be considered a validated key unless verified through other means. Compare with not sharing the key at all, the other party would have to fetch them from a key server by the fingerprint reference contained in the signature -- the key would still not be trusted, but there is a dependency on key servers.

An example, why including the key might show up useful: lots of (enterprise) companies have very strict firewall rules for server systems. You might be able to get a clearance for the repository server (or even have a Github clearance by default), but adding references for key servers might be tedious. When building the software, you might well import the key from the repository -- and issue trust based on the hard-coded public key fingerprint. Still, this is better than statically storing the key locally, as for example rolling subkeys means a broken build unless the local key copy is updated. When the key is fetched from the repository (and validated through the public primary key fingerprint), no action has to be taken.

Furthermore, there is the concept of TOFU: "trust on first use". You expect no attacker being in place when you fetch the key for the first time (for example, during initial development), but want to be sure no manipulated sources will be distributed later on. A developer fetching the key on his local development machine and setting it up as trusted might already be fine, depending on your attack model and acceptable risks.

Anyway, also but the key (or at least fingerprint, never use short key IDs) on a trusted source, as you proposed. A website available through HTTPs with a trusted certificate is a start. Especially if you're into open source projects, try to get your key certified on open source conferences (or at least have the developer keys certified, which then can certify the project key).

Should we share the public key for checking signing in the git repository?

1 Answers