Welp, there go my Git signatures

http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/

by CaliforniaKarl • 9 years ago

204 46 9 years ago

karl.kornel.us

eridius• 9 years ago

Maybe Git could leverage git-notes as a mechanism for allowing re-signing commits without changing the hashes.

hdhzy13• 9 years ago

That exactly how one can put multiple signatures on a commit.

satbyy• 9 years ago

Could you plz provide an example ?

CaliforniaKarl9• 9 years ago

Oh, interesting! There's a new thing about Git that I learned today…

With notes, I think the merge strategy may need to be changed, in case multiple people want to re-sign the same commit, but that shouldn't be too bad. The only thing left is to find a way to leverage the functionality, but having the foundation there should make it much easier!

hdhzy13• 9 years ago

Signing new commit with new subkey on top of all others is a valid strategy to deal with this problem. Another would be creating new tag and signing it with the new subkey.

For me it's not a problem that old commits are signed with revoked keys, there are several ways one can get old broken signatures (e.g. key rotation) and by design they should not be trusted.

One interesting voice in signing all commits by Linus:

Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.

Source: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

Also, depending one one's threat model signing all commits can still be not sufficient: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...

3pt14159• 9 years ago

The DAG-chain argument is kinda valid but misses the core point: I don't validate an entire codebase every time I commit. I just validate the diff. If later on a commit comes into the codebase that has some sort of evil action then it means that a host of possible scenarios can be ruled out (such as someone else easily faking the commit as me).

But if you want to get my key you have to get into my dev machine. There is a class of people that can do that, but it substantially raises the bar. Really what I would like is to make it so my Github account only accepts signed commits, so that it is impossible to impersonate me without my key.

hdhzy13• 9 years ago

I don't validate an entire codebase every time I commit.

Linus' point is that you don't need to validate the entire code base, if you have one signed commit then everything that is "below" is also (implicitly) signed. For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.

mikegerwitz• 9 years ago

One interesting voice in signing all commits by Linus:
> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.

I've never bought that argument.[0] You should use whatever method actually addresses your threat model. If you're going to sign every commit (I do), then commit (no pun intended) to doing so properly. I use `git add -p` for every commit and review my changes, and enter my smartcard PIN for every single commit. I use it to assert my identity on those commits. If you automate signing past commits, then you open yourself up to attack. Saying "this idea is stupid because everyone is going to do it wrong" is not the basis of a strong argument.

The other part of his argument is that the DAG itself allows you to just sign a single commit to verify the entire history. Firstly: that's different than signing each commit, which asserts identity of the author. Secondly, which has always been my argument, is that it rests on the security of SHA-1, which has been under question for quite a while, and has since been demonstrably broken. Are second preimage attacks unlikely with SHA-1? At least today, yes. Consider your threat model. Linus didn't even do that. He said long ago that SHA-1 was intended for integrity, not security, so retrofitting it in an argument is also not useful.

[0] https://mikegerwitz.com/papers/git-horror-story#merge-3

([0] from 2012 doesn't address the issue in this thread---expired or revoked keys.)

hdhzy13• 9 years ago

But isn't signing commits basically relying on SHA-1 values of tree and parent (this is what is signed ultimately [0])? That'd be the weakest link of the system.

[0] https://news.ycombinator.com/item?id=10353456

qznc• 9 years ago

every commit after this one will make it harder for someone to go back and change the note

Maybe you should also add some proof of work and make your commit hashes start with certain patterns?

cuckcuckspruce3• 9 years ago

Why would you have a shared SSH authentication key and PGP signing key? That just seems like a really silly idea, and leads to having to deal with situations like this.

Logging into a system remotely is a much different activity than signing a file.

richardwhiuk• 9 years ago

Not really. In both cases you are merely attesting as to who you are.

cuckcuckspruce3• 9 years ago

If you want to get pedantic, yes. However, the intent of what you are doing is, in my mind, much different.

Logging into a system expresses the intent to run something there - you want to perform some actions as a result of authenticating - it's an active process.

Signing a document is about authenticating the document - it's something passive.

CaliforniaKarl9• 9 years ago

This is the awesome part, they're actually separate keys, with separate policies!

(Or, well, separate sub-keys.)

With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.

Unfortunately, it doesn't look like you can see it on a public key server, but you can see this yourself if you have GPG, using these two commands:

gpg --keyserver pgp.mit.edu --recv-keys e5e5afc8 gpg -k e5e5afc8

(You might not need the `--keyserver pgp.mit.edu` part, if you have a keyserver specified already in your ~/.gnupg/gpg.conf file.)

(Also, I'm using GPG version 2.2.0. Older versions might not show the same content. For example, GPG 1.4.16 does not.)

The first line of output from the second command should be this:

    pub   rsa4096 2015-12-13 [SC] [expires: 2025-12-10]

That's my public key, the main part of the key, and it is only able to be used for signing stuff (the `S`), and for binding other sub-keys to the public key (the `C`).

Later on, you have entries like this:

    sub   rsa4096 2015-12-13 [E] [expires: 2025-12-10]
    sub   rsa4096 2017-10-21 [A] [expires: 2019-04-14]
    sub   rsa4096 2017-10-21 [S] [expires: 2019-04-14]

Each of those lines represents a subkey, with an explicit purpose. The first sub-key is for encryption/decryption of stuff, the second for authentication, and the third for signing.

The signing sub-key is what was generated on my Yubikey, and is used for signing stuff like email and Git commits. The authentication sub-key was _also_ generated on my Yubikey, and is what gets transformed into an SSH key.

So, each sub-key is a key in its own right. The only common things between them are that they are bound into the same GPG public key, and they are contained on the same physical device.

One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.

So yes, different activities, each with a key explicitly marked for that activity, with different policies as to how I can access it.

jlgaddis2• 9 years ago

Assuming your encryption subkey was also generated on the YubiKey, why did you not replace it as well?

hdhzy13• 9 years ago

With GPG, the only key that _has_ to be used for signing is the master key, the first key that appears in a user's key listing. For all other sub-keys, each key is explicitly marked as having a specific purpose.

Well it's only by-convention [0]:

By convention, the top-level key provides signature services, and the subkeys provide encryption services.

[0] https://tools.ietf.org/html/rfc4880#section-5.5.1.2

Personally I left the main key with Certify only (disabled Sign when creating the key with expert mode) and generated signing keys as subkeys.

One important thing to note, though, is that the OpenPGP Card standard (which the Yubikey implements) has an optional flag, which requires the PIN every time you do a signature. So, for me, the authentication key is like a local agent-stored SSH key: You "unlock" it once, and then it works for a while before you have to re-enter the PIN. But for signing, I have to re-enter the PIN every time.

A middle ground for encryption and authentication keys is Yubico's touch-to-use [1], you enter your PIN once and then have to touch the token to use the key.

[1] https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_...

cuckcuckspruce3• 9 years ago

Okay, I hadn't followed that in your post. Thank you for clarifying.

jwilk2• 9 years ago

I don’t have a record of every signature I made.

Somebody please make a search engine for public OpenPGP signatures.

Karunamon• 9 years ago

That’s basically a key server isn’t it? pgp.mit and others

jwilk2• 9 years ago

I want to find all signatures made by key CDB5A1243ACDB63009AD07212D4EB3A6015475F5.

How does a key server help me?

kanzure• 9 years ago

I don’t have a record of every signature I made

Use opentimestamps git wrapper. Each commit is signed and timestamped. When you revoke your key, the original signed commit is still timestamped, presumably before your revocation date.

https://github.com/opentimestamps/opentimestamps-client

https://opentimestamps.org/

CaliforniaKarl9• 9 years ago

Dude. That looks awesome. It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet), but that would probably need messing with GPG in some way.

(What I mean is, a GPG signature includes a space for "sub-packets" of information, stored in in "length-type-value" form. See RFC 4480 Section 5.2.3 for the overall signature packet format. The OpenTimestamp data could be embedded as a sub-packet, causing its content to also be signed.)

It looks like this site was posted 12 days ago by handpickednames in https://news.ycombinator.com/item?id=15456521, but it didn't get must attention. I think people should check it out!

(Disclaimer: I don't have any position in Bitcoin or blockchain right now.)

hdhzy13• 9 years ago

It kindof annoys me that the timestamp wasn't somehow worked into the signature itself (like as a sub-packet),

Interesting, I took a sample signature from here [0], saved that to file and run `gpg --list-packets gitsig.asc`:

    # off=0 ctb=89 tag=2 hlen=3 plen=284
    :signature packet: algo 1, keyid 5D3EB2F8800430EB
        version 4, created 1399174181, md5len 0, sigclass 0x00
        digest algo 2, begin of digest 65 b4
        hashed subpkt 2 len 4 (sig created 2014-05-04)
        subpkt 16 len 8 (issuer key ID 5D3EB2F8800430EB)
        data: [2047 bits]

It looks like it is timestamped with date 2014-05-04T03:29:41.000Z. The tag itself also has Date header, usually the tag is created and signed at the same time.

[0] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

OpenTimestamps protects against someone backdating signatures. If they control the key they can create signatures with arbitrary dates but they can't put them in the blockchain in any place. So basically that gives "proof of existence" that the given signature existed at least at that exact point of time. Disclaimer: I never used OpenTimestamps but rather Bitcoin Core JSON interface to timestamp things (it's 3 simple commands to publish OP_RETURN transaction).

For people that don't want to spend Bitcoin on timestamping it is possible to (ab)use Certificate Transparency logs for the same purpose: https://wiki.mozilla.org/Security/Binary_Transparency

petertodd3• 9 years ago

but that would probably need messing with GPG in some way.

That's exactly why I didn't do that: the OpenPGP standard is extremely complex, good libraries to do that kind of thing just don't exist, and it was unclear what compatibility issues I'd be adding if I did that.

petertodd3• 9 years ago

I also have a blog post describing the Git timestamping use-case: https://petertodd.org/2016/opentimestamps-git-integration

Welp, there go my Git signatures

Related Stories