7 ms·

What does a PGP signature on a Git commit prove?

147 points by JNRowe 6y ago

nuisance-bear 6y ago
There's a cautionary note at the end of the article reminding the reader that git still relies on sha1 (with mitigations). Recall that $10k worth of GTX1060's produced a sha1 collision in late 2019. https://www.usenix.org/conference/usenixsecurity20/presentation/leurent https://www.usenix.org/conference/usenixsecurity20/presentat...
bawolff 6y ago
Totally though this was going to be some snarky article claiming they're worthless. Refreshing to see the article just ernestly answers the headline. > To my knowledge, there are no effective attacks against sha1 as used by git Perhaps im missing something, but wouldn't a chosen prefix collision be relavent here? I imagine the real reason is that cost to pull it off for sha1 is somewhere in the $10,000-$100,000 range (but getting cheaper every year) which is lots of $$$ to attack something without an obvious attack scenario that can justify it.
- petertodd 6y ago
  So the big problem with Git and SHA1 is that in many cases you are giving full control to an untrusted third party over the sha1 hash of something. For example, if you merge a binary file, it'd be quite easy for them to generate two different versions of the same file, with the same SHA1 digest, and then use the second version to cause problems in the future. You may also be able to modify a text file in the same way without getting noticed in review (I'm not up to speed on how advanced sha1 collision techniques are now). Similarly, the git commits you merge themselves could have that done - the actual git commit serialization gives you a fair bit of ability to append stuff to it that isn't shown in the UI. That wouldn't affect the signed git commits. But it's still dubious to have the ability to change old history in a checkout. Anyway, Git is apparently moving towards SHA256 support, so hopefully this problem will be fixed soon: https://lwn.net/Articles/823352/ https://lwn.net/Articles/823352/
  - thephyber 6y ago
    > it'd be quite easy for them to generate two different versions of the same file Citation needed. When SHA1 was cracked, it cost $110k worth of cloud computing. And there was some restriction on the two files which matched checksums. IIRC it was like the Birthday Paradox — you don’t pick one and find another sharing the same match, but you generate billions of mutations of similar binaries and statistically two would have the same checksum. Not exactly easy, fast, cheap, or work with all use cases.
    - cratermoon 6y ago
      It was $11K https://www.usenix.org/conference/usenixsecurity20/presentation/leurent https://www.usenix.org/conference/usenixsecurity20/presentat...
      - bawolff 6y ago
        That was a later attack, not the original. Attacks get cheaper with time.
    - westurner 6y ago
      That nonce value could be ±\0 or 5,621,964,321e100; though for well-designed cryptographic hash functions it's far less likely that - at maximum difficulty - a low nonce value will result in a hash collision.
      - bawolff 6y ago
        ? How are nonces even involved in this?
        westurner 6y ago
        Searching for the value to prepend or append that causes a hash collision is exactly the same as finding a nonce value at maximum difficulty (not less than the difficulty value, exactly equal to the target hash). Mutate and check.
- slavik81 6y ago
  Git migrated to a hardened variant of SHA-1 back in v2.13. https://github.blog/2017-05-10-git-2-13-has-been-released/#sha-1-collision-detection https://github.blog/2017-05-10-git-2-13-has-been-released/#s...
petertodd 6y ago
Shameless plug: you can mostly(1) solve the problem of Git PGP signatures becoming unverifiable due to key compromise with my OpenTimestamps software: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration tl;dr: it proves data existed in the past. In the case of a PGP signature on a Git commit, that can prove the signature (and the repo contents) were created prior to the key being compromised. 1) Mostly, because sometimes you don't know when the key was compromised.
- bawolff 6y ago
  Nice to see a non-bullshit application for blockchains :)
  - petertodd 6y ago
    Note that OpenTimestamps itself doesn't actually use a blockchain. But while the protocol supports multiple time attestation mechanisms, almost everyone using OTS uses it in conjunction with Bitcoin (the public calendars all timestamp via Bitcoin). Thus almost all OTS timestamps are depending on the Bitcoin blockchain for their timestamp security.
    - Woung1938 6y ago
      Is there a high-to-low level design document to read on how to verify the timestamp? A simple OP_RETURN + hash output in a transaction is dead simple to verify (just get the transaction from any place, see the output, check the timestamp). I'd like to compare OTS with it.
      - petertodd 6y ago
        Not really. But if you understand the basics of how OTS works, it's fairly easy to figure out how to do that with the `ots info` command. Basically, it just prints out the raw commitment operations the timestamp proof performs, letting you follow along. Note that OTS proofs do not have any notion of a transaction in them. Rather, they perform commitment operations that end up at a merkle root of a Bitcoin block (at least in the 99.9999% of proofs that use Bitcoin). With the `--no-bitcoin` option, the OTS client will tell you what block # to look for, and what the merkle should be for the proof to be valid.
waynesonfire 6y ago
> Obligatory note: sha1 is not considered sufficiently strong for hashing purposes these days, and this is widely acknowledged by the git development community. Significant efforts are under way to migrate git to stronger cryptographic hashes Ops, forgot to add a tag to your hash algorithm?
phs318u 6y ago
That the committer hopes you believe they manage their PGP private key better than they manage their Git account security?
- asguy 6y ago
  Which “git account”? Signing means you don’t need to depend on the git mirrors security to ensure you know who made a commit.
- bawolff 6y ago
  Git doesn't have accounts. Its a program you run on your computer.
- shawabawa3 6y ago
  You know anyone can push a commit "authored" by any GitHub user? And the GitHub UI will happily show as that user Gpg signature's are the only way of having any verification at all on who wrote a commit
- phs318u 6y ago
  To the above commenters, Git is also used in enterprise scenarios with private, semi-private repos that enforce corporate user auth. My initial comment was dumb and deserved downvotes, but all git usage isn't the git usage you know of.
nerdponx 6y ago
> If we cared to, we could walk each commit all the way back to the beginning of Linux git history, but we don't need to do that — verifying the checksum of the latest commit is sufficient to provide us all the necessary assurances about the entire history of that tree. Doesn't this imply a tremendous amount of trust in the signer? It sounds like it's only a guarantee about history if every commit was signed.
- goerz 6y ago
  It's not a matter of trusting the signer. Every commit includes the hash of its parent, and thus the combined hashes of all its ancestors. Signing just the last commits signs the entire chain.
  - swsieber 6y ago
    Right... but where did the signer get the previous commits?
    - goerz 6y ago
      Oh, I see what you mean. But a signed commit doesn’t imply that the signer vouches for the code or it’s history (unless they say they do, but then you have to believe them that they reviewed the entire history). What it does do is to guarantee that after a commit is signed, nobody can come in and retroactively alter the history of the repo.
      - nerdponx 6y ago
        What if there are 5 unsigned consecutive commits somewhere in the middle of the chain? Or is the idea that you still can't alter anything in that unsigned section without altering the signed commits at the ends?
        goerz 6y ago
        Yes, that’s exactly the idea
gavindean90 6y ago
SHA1 wasn’t meant to be a security measure but as far as I know no one has been able to generate a collision that could fool a code review. > Just replacing an object in a repository is not enough; the attacker would have to find a way to distribute that object to other repositories around the world, which is not an easy task. The colliding object would have to function as C source (if the kernel were the target of attack here), and would have to stand up to a casual inspection — it would have to look like proper kernel source. https://lwn.net/Articles/715716/ https://lwn.net/Articles/715716/
- ganafagol 6y ago
  > SHA1 wasn’t meant to be a security measure It literally stands for Secure Hashing Algorithm.
  - detaro 6y ago
    presumably the mean that the use of SHA1 in git wasn't meant to be a security measure.
- petertodd 6y ago
  Regardless of whether or not SHA1 was meant to be a security measure, it should have been. Linus's original thinking re: git security is much less useful than just having a secure hash function that you can rely on.
deleted 6y ago
[deleted]
globular-toast 6y ago
Something that is not discussed: to verify the signature you need a copy of Linus's public key, but how do you know you have his actual public key? If you downloaded the key from some server somewhere, and that server was compromised, it could fool you into thinking the signature is valid, which undermines the whole thing. One way to know the key is valid is if you meet Linus himself and verify it first hand (like when you verify Whatsapp keys, which you do, right?). But not everyone can do that. PGP implements a "web of trust" security model. That means if someone you trust has signed Linus's key, you can verify his key via their signature. This extends beyond one hop; it's up to you how much you trust it based on its signatures. This is in contrast to centralised systems like SSL/TLS where you have no choice but to trust entities like Microsoft, Google, Verisign etc.
- rdpintqogeogsaa 6y ago
  In practice, most people don't care if they have a copy of Linus's public key. They only care if they have a copy that is sufficiently likely to be Linus's public key. This is the reason why the web of trust has, by and large, failed to reach any noteworthy amount of adoption. The web/operating system PKI is good enough for most purposes. Unless your usage scenario involves a massively critical government agency with good reason to be actually paranoid, "good enough" for the web means "good enough" to deliver a public key for the Linux kernel. Or more likely, "good enough" to deliver an installation image for the distribution of your choice that is theoretically signed with PGP/something actually reasonable, but whose signature you won't check anyway because the web PKI is, in fact, good enough. The distribution of your choice may then possibly have verified the source of the public key, but that's so far upstream of you that, quite honestly, you have no way of checking anyway. Even if you bothered checking this being checked upstream, there are tons of other critical system components for which you would have to repeat this.
- waynesonfire 6y ago
  > Kernel.org web of trust PGP keys used by members of kernel.org are cross-signed by other members of the Linux kernel development community (and, frequently, by many other people). If you wanted to verify the validity of any key belonging to a member of kernel.org, you could review the list of signatures on their public key and then make a decision whether you trust that key or not. See the Wikipedia article on the subject of the Web of Trust. https://www.kernel.org/signature.html https://www.kernel.org/signature.html Looks like the kernel.org folks actually use the web of trust model.
numbsafari 6y ago
Are there alternatives to PGP for commit/tag signing?
- upofadown 6y ago
  Not really. There are utilities that sign things (e.g. Signify) but they don't attempt to solve the difficult problem of identity management. Also, OpenPGP is an open published standard with an extensive infrastructure of implementations. It's hard to overcome that with a new proposal.
rakoo 6y ago
> The difference between signed tags and signed commits is minimal — in the case of commit signing, the signature goes into the commit object itself. It is generally a good practice to PGP-sign commits Note: Linus says otherwise, the two are very different: 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... One of the most important reasons it doesn't make sense to sign commits is that keys expire so when you sign something you implicitly say it is valid at most until the key is valid; nothing can be guaranteed after that. It is easy enough to re-sign a tag (even automatically) but you can't re-sign a commit without changing its identity and that defeats the whole purpose of git. The only reason you'd want to sign commits is to defend from malicious maintainers ie if your patch is changed before being merged, or your authorship is removed, or a patch impersonating you is merged. It's probably better to sign your patches (ie the temporary moment where you interact) in that case: I see there was some work in that direction (https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/) but apparently it hasn't caught up (https://lore.kernel.org/signatures/ https://lore.kernel.org/signatures/ shows last signatures end of 2020)
- waynesonfire 6y ago
  Why is this a problem, the key was valid however at the time the commit was made? > https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/ Huh? Replace one convoluted process for another convoluted and less capable one? Seems like not invented here syndrome. Not surprised it's not used. If you're using email for critical, sensitive work, spend the 15 minutes to learn how PGP works and another to set it up. You can even sign your git commits and tags with them! Also, get some yubikeys, they work well with pgp.
  - rakoo 6y ago
    I think you need 15 minutes to understand what the problem is about. An email-based workflow like the one the linux tree uses is based on patches, not commits. You may want to sign commits but it will be useless because commits aren't exchanged. So the proposed process doesn't "replace" anything: there's no signing in the first place. You can't sign patches directly because then they wouldn't be usable by the git tools like git-am. So you need a meta data-structure that contains all patches and relevant information kinda like a pseudo-commit: the author, message and patch itself. Then that meta data-structure can be pgp-encrypted and sent by email, as described by your link and as you implied was not done > Why is this a problem, the key was valid however at the time the commit was made? You want to check the validity of a commit at the moment you use it, not the moment the commit was made: imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired. What's the use of that signature ? Can a third-party cherry-pick that commit and trusting that "the key was valid at the time the commit was made" ? You can sign that you did something at some point but you can't sign that you never did something, or that you never used a given key. > spend the 15 minutes to learn how PGP works and another to set it up You can't seriously believe that it takes 15 minutes to understand how PGP works and 15 minutes to set up a functional environment and expect it to follow the best standards. Even reading the kernel's documentation on how to use pgp (https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-guide.html# https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-...) takes more than 15 minutes. > Also, get some yubikeys, they work well with pgp. I don't understand what's the link with the rest of the discussion
exabrial 6y ago
I think the most valuable aspect of signed commits is that of also signing the contributor license agreement with the same key. This is the Apache Source Foundation's policy.
deleted 6y ago
[deleted]
kazinator 6y ago
> With git, a cryptographic signature on a commit provides strong integrity guarantees of the entire history of that branch going backwards, including all metadata and all contents of the repository, all the way back to the initial commit. The purpose of a signature is to add authenticity assurances on top of integrity guarantees (which are necessary to authenticity, but independent). A document is signed by producing a digest of it, and that digest provides an integrity guarantee. The signature of the digest is then an additional authenticity guarantee. "Integrity guarantees" means that it is vanishingly unlikely that someone can make a maliciously altered clone of that repository, including its history, all the way to the initial commit, including that signature. The git hashes already provide pretty strong integrity guarantees of this sort. We can be confident that someone re-creating a fake history cannot end up at the same baseline at the HEAD, with the same commit hash. The strength of that confidence could be increased simply by adding additional, stronger hashes as part of a commit's content. In terms of authenticity, the signature provides confidence (not a "guarantee") that whoever signed that commit held some beliefs about the repository, sufficient to want to put their signature to it Someone could be duped into signing a corrupted repository, believing it to be genuine, in which case their beliefs were wrong. (And do not necessarily match their present beliefs!) Someone could be coerced into signing corrupted repository, in which case their beliefs at the time of signing are that the repository is malicious, and that that they will be harmed if they don't comply. Someone's private key could be compromised, so that an unauthorized agent perpetrates their signature without their knowledge or consent. An authenticity assurance is not as easily quantifiable as an integrity guarantee. The integrity guarantee rests in the digest algorithm (how difficult is it to produce a document matching a given digest), but authencity assurances involve people problems.

147 points by JNRowe 6y ago

There's a cautionary note at the end of the article reminding the reader that git still relies on sha1 (with mitigations). Recall that $10k worth of GTX1060's produced a sha1 collision in late 2019. https://www.usenix.org/conference/usenixsecurity20/presentation/leurent https://www.usenix.org/conference/usenixsecurity20/presentat...

bawolff 6y ago

Totally though this was going to be some snarky article claiming they're worthless. Refreshing to see the article just ernestly answers the headline. > To my knowledge, there are no effective attacks against sha1 as used by git Perhaps im missing something, but wouldn't a chosen prefix collision be relavent here? I imagine the real reason is that cost to pull it off for sha1 is somewhere in the $10,000-$100,000 range (but getting cheaper every year) which is lots of $$$ to attack something without an obvious attack scenario that can justify it.

petertodd 6y ago
So the big problem with Git and SHA1 is that in many cases you are giving full control to an untrusted third party over the sha1 hash of something. For example, if you merge a binary file, it'd be quite easy for them to generate two different versions of the same file, with the same SHA1 digest, and then use the second version to cause problems in the future. You may also be able to modify a text file in the same way without getting noticed in review (I'm not up to speed on how advanced sha1 collision techniques are now). Similarly, the git commits you merge themselves could have that done - the actual git commit serialization gives you a fair bit of ability to append stuff to it that isn't shown in the UI. That wouldn't affect the signed git commits. But it's still dubious to have the ability to change old history in a checkout. Anyway, Git is apparently moving towards SHA256 support, so hopefully this problem will be fixed soon: https://lwn.net/Articles/823352/ https://lwn.net/Articles/823352/
- thephyber 6y ago
  > it'd be quite easy for them to generate two different versions of the same file Citation needed. When SHA1 was cracked, it cost $110k worth of cloud computing. And there was some restriction on the two files which matched checksums. IIRC it was like the Birthday Paradox — you don’t pick one and find another sharing the same match, but you generate billions of mutations of similar binaries and statistically two would have the same checksum. Not exactly easy, fast, cheap, or work with all use cases.
  - cratermoon 6y ago
    It was $11K https://www.usenix.org/conference/usenixsecurity20/presentation/leurent https://www.usenix.org/conference/usenixsecurity20/presentat...
    - bawolff 6y ago
      That was a later attack, not the original. Attacks get cheaper with time.
  - westurner 6y ago
    That nonce value could be ±\0 or 5,621,964,321e100; though for well-designed cryptographic hash functions it's far less likely that - at maximum difficulty - a low nonce value will result in a hash collision.
    - bawolff 6y ago
      ? How are nonces even involved in this?
      - westurner 6y ago
        Searching for the value to prepend or append that causes a hash collision is exactly the same as finding a nonce value at maximum difficulty (not less than the difficulty value, exactly equal to the target hash). Mutate and check.
slavik81 6y ago
Git migrated to a hardened variant of SHA-1 back in v2.13. https://github.blog/2017-05-10-git-2-13-has-been-released/#sha-1-collision-detection https://github.blog/2017-05-10-git-2-13-has-been-released/#s...

petertodd 6y ago

Shameless plug: you can mostly(1) solve the problem of Git PGP signatures becoming unverifiable due to key compromise with my OpenTimestamps software: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration tl;dr: it proves data existed in the past. In the case of a PGP signature on a Git commit, that can prove the signature (and the repo contents) were created prior to the key being compromised. 1) Mostly, because sometimes you don't know when the key was compromised.

bawolff 6y ago
Nice to see a non-bullshit application for blockchains :)
- petertodd 6y ago
  Note that OpenTimestamps itself doesn't actually use a blockchain. But while the protocol supports multiple time attestation mechanisms, almost everyone using OTS uses it in conjunction with Bitcoin (the public calendars all timestamp via Bitcoin). Thus almost all OTS timestamps are depending on the Bitcoin blockchain for their timestamp security.
  - Woung1938 6y ago
    Is there a high-to-low level design document to read on how to verify the timestamp? A simple OP_RETURN + hash output in a transaction is dead simple to verify (just get the transaction from any place, see the output, check the timestamp). I'd like to compare OTS with it.
    - petertodd 6y ago
      Not really. But if you understand the basics of how OTS works, it's fairly easy to figure out how to do that with the `ots info` command. Basically, it just prints out the raw commitment operations the timestamp proof performs, letting you follow along. Note that OTS proofs do not have any notion of a transaction in them. Rather, they perform commitment operations that end up at a merkle root of a Bitcoin block (at least in the 99.9999% of proofs that use Bitcoin). With the `--no-bitcoin` option, the OTS client will tell you what block # to look for, and what the merkle should be for the proof to be valid.

waynesonfire 6y ago

> Obligatory note: sha1 is not considered sufficiently strong for hashing purposes these days, and this is widely acknowledged by the git development community. Significant efforts are under way to migrate git to stronger cryptographic hashes Ops, forgot to add a tag to your hash algorithm?

phs318u 6y ago

That the committer hopes you believe they manage their PGP private key better than they manage their Git account security?

asguy 6y ago
Which “git account”? Signing means you don’t need to depend on the git mirrors security to ensure you know who made a commit.
bawolff 6y ago
Git doesn't have accounts. Its a program you run on your computer.
shawabawa3 6y ago
You know anyone can push a commit "authored" by any GitHub user? And the GitHub UI will happily show as that user Gpg signature's are the only way of having any verification at all on who wrote a commit
phs318u 6y ago
To the above commenters, Git is also used in enterprise scenarios with private, semi-private repos that enforce corporate user auth. My initial comment was dumb and deserved downvotes, but all git usage isn't the git usage you know of.

nerdponx 6y ago

> If we cared to, we could walk each commit all the way back to the beginning of Linux git history, but we don't need to do that — verifying the checksum of the latest commit is sufficient to provide us all the necessary assurances about the entire history of that tree. Doesn't this imply a tremendous amount of trust in the signer? It sounds like it's only a guarantee about history if every commit was signed.

goerz 6y ago
It's not a matter of trusting the signer. Every commit includes the hash of its parent, and thus the combined hashes of all its ancestors. Signing just the last commits signs the entire chain.
- swsieber 6y ago
  Right... but where did the signer get the previous commits?
  - goerz 6y ago
    Oh, I see what you mean. But a signed commit doesn’t imply that the signer vouches for the code or it’s history (unless they say they do, but then you have to believe them that they reviewed the entire history). What it does do is to guarantee that after a commit is signed, nobody can come in and retroactively alter the history of the repo.
    - nerdponx 6y ago
      What if there are 5 unsigned consecutive commits somewhere in the middle of the chain? Or is the idea that you still can't alter anything in that unsigned section without altering the signed commits at the ends?
      - goerz 6y ago
        Yes, that’s exactly the idea

gavindean90 6y ago

SHA1 wasn’t meant to be a security measure but as far as I know no one has been able to generate a collision that could fool a code review. > Just replacing an object in a repository is not enough; the attacker would have to find a way to distribute that object to other repositories around the world, which is not an easy task. The colliding object would have to function as C source (if the kernel were the target of attack here), and would have to stand up to a casual inspection — it would have to look like proper kernel source. https://lwn.net/Articles/715716/ https://lwn.net/Articles/715716/

ganafagol 6y ago
> SHA1 wasn’t meant to be a security measure It literally stands for Secure Hashing Algorithm.
- detaro 6y ago
  presumably the mean that the use of SHA1 in git wasn't meant to be a security measure.
petertodd 6y ago
Regardless of whether or not SHA1 was meant to be a security measure, it should have been. Linus's original thinking re: git security is much less useful than just having a secure hash function that you can rely on.

deleted 6y ago

[deleted]

globular-toast 6y ago

Something that is not discussed: to verify the signature you need a copy of Linus's public key, but how do you know you have his actual public key? If you downloaded the key from some server somewhere, and that server was compromised, it could fool you into thinking the signature is valid, which undermines the whole thing. One way to know the key is valid is if you meet Linus himself and verify it first hand (like when you verify Whatsapp keys, which you do, right?). But not everyone can do that. PGP implements a "web of trust" security model. That means if someone you trust has signed Linus's key, you can verify his key via their signature. This extends beyond one hop; it's up to you how much you trust it based on its signatures. This is in contrast to centralised systems like SSL/TLS where you have no choice but to trust entities like Microsoft, Google, Verisign etc.

rdpintqogeogsaa 6y ago
In practice, most people don't care if they have a copy of Linus's public key. They only care if they have a copy that is sufficiently likely to be Linus's public key. This is the reason why the web of trust has, by and large, failed to reach any noteworthy amount of adoption. The web/operating system PKI is good enough for most purposes. Unless your usage scenario involves a massively critical government agency with good reason to be actually paranoid, "good enough" for the web means "good enough" to deliver a public key for the Linux kernel. Or more likely, "good enough" to deliver an installation image for the distribution of your choice that is theoretically signed with PGP/something actually reasonable, but whose signature you won't check anyway because the web PKI is, in fact, good enough. The distribution of your choice may then possibly have verified the source of the public key, but that's so far upstream of you that, quite honestly, you have no way of checking anyway. Even if you bothered checking this being checked upstream, there are tons of other critical system components for which you would have to repeat this.
waynesonfire 6y ago
> Kernel.org web of trust PGP keys used by members of kernel.org are cross-signed by other members of the Linux kernel development community (and, frequently, by many other people). If you wanted to verify the validity of any key belonging to a member of kernel.org, you could review the list of signatures on their public key and then make a decision whether you trust that key or not. See the Wikipedia article on the subject of the Web of Trust. https://www.kernel.org/signature.html https://www.kernel.org/signature.html Looks like the kernel.org folks actually use the web of trust model.

numbsafari 6y ago

Are there alternatives to PGP for commit/tag signing?

upofadown 6y ago
Not really. There are utilities that sign things (e.g. Signify) but they don't attempt to solve the difficult problem of identity management. Also, OpenPGP is an open published standard with an extensive infrastructure of implementations. It's hard to overcome that with a new proposal.

rakoo 6y ago

> The difference between signed tags and signed commits is minimal — in the case of commit signing, the signature goes into the commit object itself. It is generally a good practice to PGP-sign commits Note: Linus says otherwise, the two are very different: 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... One of the most important reasons it doesn't make sense to sign commits is that keys expire so when you sign something you implicitly say it is valid at most until the key is valid; nothing can be guaranteed after that. It is easy enough to re-sign a tag (even automatically) but you can't re-sign a commit without changing its identity and that defeats the whole purpose of git. The only reason you'd want to sign commits is to defend from malicious maintainers ie if your patch is changed before being merged, or your authorship is removed, or a patch impersonating you is merged. It's probably better to sign your patches (ie the temporary moment where you interact) in that case: I see there was some work in that direction (https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/) but apparently it hasn't caught up (https://lore.kernel.org/signatures/ https://lore.kernel.org/signatures/ shows last signatures end of 2020)

waynesonfire 6y ago
Why is this a problem, the key was valid however at the time the commit was made? > https://lwn.net/Articles/813646/ https://lwn.net/Articles/813646/ Huh? Replace one convoluted process for another convoluted and less capable one? Seems like not invented here syndrome. Not surprised it's not used. If you're using email for critical, sensitive work, spend the 15 minutes to learn how PGP works and another to set it up. You can even sign your git commits and tags with them! Also, get some yubikeys, they work well with pgp.
- rakoo 6y ago
  I think you need 15 minutes to understand what the problem is about. An email-based workflow like the one the linux tree uses is based on patches, not commits. You may want to sign commits but it will be useless because commits aren't exchanged. So the proposed process doesn't "replace" anything: there's no signing in the first place. You can't sign patches directly because then they wouldn't be usable by the git tools like git-am. So you need a meta data-structure that contains all patches and relevant information kinda like a pseudo-commit: the author, message and patch itself. Then that meta data-structure can be pgp-encrypted and sent by email, as described by your link and as you implied was not done > Why is this a problem, the key was valid however at the time the commit was made? You want to check the validity of a commit at the moment you use it, not the moment the commit was made: imagine I put up a fake tree, with a fake commit with you as an author but made with a fake key that already expired. What's the use of that signature ? Can a third-party cherry-pick that commit and trusting that "the key was valid at the time the commit was made" ? You can sign that you did something at some point but you can't sign that you never did something, or that you never used a given key. > spend the 15 minutes to learn how PGP works and another to set it up You can't seriously believe that it takes 15 minutes to understand how PGP works and 15 minutes to set up a functional environment and expect it to follow the best standards. Even reading the kernel's documentation on how to use pgp (https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-guide.html# https://www.kernel.org/doc/html/v5.1/process/maintainer-pgp-...) takes more than 15 minutes. > Also, get some yubikeys, they work well with pgp. I don't understand what's the link with the rest of the discussion

exabrial 6y ago

I think the most valuable aspect of signed commits is that of also signing the contributor license agreement with the same key. This is the Apache Source Foundation's policy.

deleted 6y ago

[deleted]

kazinator 6y ago

> With git, a cryptographic signature on a commit provides strong integrity guarantees of the entire history of that branch going backwards, including all metadata and all contents of the repository, all the way back to the initial commit. The purpose of a signature is to add authenticity assurances on top of integrity guarantees (which are necessary to authenticity, but independent). A document is signed by producing a digest of it, and that digest provides an integrity guarantee. The signature of the digest is then an additional authenticity guarantee. "Integrity guarantees" means that it is vanishingly unlikely that someone can make a maliciously altered clone of that repository, including its history, all the way to the initial commit, including that signature. The git hashes already provide pretty strong integrity guarantees of this sort. We can be confident that someone re-creating a fake history cannot end up at the same baseline at the HEAD, with the same commit hash. The strength of that confidence could be increased simply by adding additional, stronger hashes as part of a commit's content. In terms of authenticity, the signature provides confidence (not a "guarantee") that whoever signed that commit held some beliefs about the repository, sufficient to want to put their signature to it Someone could be duped into signing a corrupted repository, believing it to be genuine, in which case their beliefs were wrong. (And do not necessarily match their present beliefs!) Someone could be coerced into signing corrupted repository, in which case their beliefs at the time of signing are that the repository is malicious, and that that they will be harmed if they don't comply. Someone's private key could be compromised, so that an unauthorized agent perpetrates their signature without their knowledge or consent. An authenticity assurance is not as easily quantifiable as an integrity guarantee. The integrity guarantee rests in the digest algorithm (how difficult is it to produce a document matching a given digest), but authencity assurances involve people problems.