7 ms·

Welp, there go my Git signatures

204 points by CaliforniaKarl 9y ago

eridius 9y ago
Maybe Git could leverage git-notes as a mechanism for allowing re-signing commits without changing the hashes.
- hdhzy 9y ago
  That exactly how one can put multiple signatures on a commit.
  - satbyy 9y ago
    Could you plz provide an example ?
    - hdhzy 9y ago
      Check out Notes Towards Detached Signatures in Git [0]. [0]: https://grimoire.ca/git/detached-sigs https://grimoire.ca/git/detached-sigs
      - CaliforniaKarl 9y ago
        That's interesting! You should post that to HN directly, since it hasn't been posted before.
        hdhzy 9y ago
        Git's underlying data model is simple yet extremely flexible (see e.g. [0]), well just like OpenPGP I guess. As for the article you're welcome to post it yourself :) [0]: https://github.com/google/git-appraise https://github.com/google/git-appraise
- CaliforniaKarl 9y 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!
hdhzy 9y 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-td2582986.html 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/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
- 3pt14159 9y 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.
  - hdhzy 9y 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.
qznc 9y 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?
cuckcuckspruce 9y 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 9y ago
  Not really. In both cases you are merely attesting as to who you are.
  - cuckcuckspruce 9y 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.
- CaliforniaKarl 9y 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.
jwilk 9y ago
> I don’t have a record of every signature I made. Somebody please make a search engine for public OpenPGP signatures.
- Karunamon 9y ago
  That’s basically a key server isn’t it? pgp.mit and others
  - jwilk 9y ago
    I want to find all signatures made by key CDB5A1243ACDB63009AD07212D4EB3A6015475F5. How does a key server help me?
deleted 9y ago
[deleted]
kanzure 9y 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://github.com/opentimestamps/opentimestamps-client https://opentimestamps.org/ https://opentimestamps.org/
- CaliforniaKarl 9y 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 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.)
  - hdhzy 9y 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 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 https://wiki.mozilla.org/Security/Binary_Transparency

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

hdhzy 9y ago
That exactly how one can put multiple signatures on a commit.
- satbyy 9y ago
  Could you plz provide an example ?
  - hdhzy 9y ago
    Check out Notes Towards Detached Signatures in Git [0]. [0]: https://grimoire.ca/git/detached-sigs https://grimoire.ca/git/detached-sigs
    - CaliforniaKarl 9y ago
      That's interesting! You should post that to HN directly, since it hasn't been posted before.
      - hdhzy 9y ago
        Git's underlying data model is simple yet extremely flexible (see e.g. [0]), well just like OpenPGP I guess. As for the article you're welcome to post it yourself :) [0]: https://github.com/google/git-appraise https://github.com/google/git-appraise
CaliforniaKarl 9y 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!

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-td2582986.html 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/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...

3pt14159 9y 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.
- hdhzy 9y 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.

qznc 9y 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?

cuckcuckspruce 9y 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 9y ago
Not really. In both cases you are merely attesting as to who you are.
- cuckcuckspruce 9y 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.
CaliforniaKarl 9y 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.

jwilk 9y ago

> I don’t have a record of every signature I made. Somebody please make a search engine for public OpenPGP signatures.

Karunamon 9y ago
That’s basically a key server isn’t it? pgp.mit and others
- jwilk 9y ago
  I want to find all signatures made by key CDB5A1243ACDB63009AD07212D4EB3A6015475F5. How does a key server help me?

deleted 9y ago

[deleted]

kanzure 9y 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://github.com/opentimestamps/opentimestamps-client https://opentimestamps.org/ https://opentimestamps.org/

CaliforniaKarl 9y 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 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.)
- hdhzy 9y 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 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 https://wiki.mozilla.org/Security/Binary_Transparency