Earlier quoted context omitted.
This is the opposite of a specific threat vector
Software supply chain attacks not specific enough?
Not in terms of specific threat model.
Use KeePassXC to sign your Git commits
11–20 of 29 posts
Re: Use KeePassXC to sign your Git commits
#12I tend to agree with the argument Linus put forward a long time ago, saying that there is little reason to sign commits instead of tags in git.
* Commit references the tree. If you sign the entire commit object – which is what you want, not leaving a way to change something about the commit without invalidating the signature – you sign the file tree as you saw it and implicitly all its history. Might as well sign the tag then.
* Signatures separable from the commit have a benefit of allowing someone other than the author and committer at the time to certify authenticity of the file tree. For example, if the key needs to be rotated later, you can slap a new signature over the previous one.
* Signing every single commit is tedious, so you're bound to get it automated at some point. Now your signatures are worth less because your keys are always around to indiscriminately, automatically sign whatever.
Re: Use KeePassXC to sign your Git commits
#13Honestly, I don't get the point of it. SSH keys, unlike PGP keys, are meant to be disposable and don't carry any identity information. If anything, I'd rather use my PGP keys with SSH (an option available for about a decade I think).
Re: Use KeePassXC to sign your Git commits
#14I tend to agree with the argument Linus put forward a long time ago, saying that there is little reason to sign commits instead of tags in git. * Commit references the tree. If you sign the entire commit object – which is what you want, not leaving a way to change something about the commit without invalidating the signature – you sign the file tree as you saw it and implicitly all its history. Might as well sign the…
The last point can be mitigated by a hardware based security key(nitrokey,yubikey,etc).
Key would then by not on your device so extraction would be difficult or impossible.
You would need to touch the key to grant the sign request which would prevent any signing without you noticing.
Re: Use KeePassXC to sign your Git commits
#15Re: Use KeePassXC to sign your Git commits
#16Re: Use KeePassXC to sign your Git commits
#17[flagged]
Re: Use KeePassXC to sign your Git commits
#18I tend to agree with the argument Linus put forward a long time ago, saying that there is little reason to sign commits instead of tags in git. * Commit references the tree. If you sign the entire commit object – which is what you want, not leaving a way to change something about the commit without invalidating the signature – you sign the file tree as you saw it and implicitly all its history. Might as well sign the…
I think ssh keys signing goes a long way to point 3. I haven't looks if you can (or if it matters) to sign with an ssh certificate, but that would be useful to add some context to the signature too.
Re: Use KeePassXC to sign your Git commits
#19Honestly, I don't get the point of it. SSH keys, unlike PGP keys, are meant to be disposable and don't carry any identity information. If anything, I'd rather use my PGP keys with SSH (an option available for about a decade I think).
People don't get the security concepts. Probably, just a lot of people wanted signed commits because they somehow "better", but couldn't get PGP to work.
But they use SSH keys to push to GitHub anyway, so someone added the option to use SSH keys to sign Git commits. Now everyone can have a green "Verified" symbol on their commits.
It's worth less, but it looks better!
Re: Use KeePassXC to sign your Git commits
#20I tend to agree with the argument Linus put forward a long time ago, saying that there is little reason to sign commits instead of tags in git. * Commit references the tree. If you sign the entire commit object – which is what you want, not leaving a way to change something about the commit without invalidating the signature – you sign the file tree as you saw it and implicitly all its history. Might as well sign the…
The last point can be mitigated by a hardware based security key(nitrokey,yubikey,etc). Key would then by not on your device so extraction would be difficult or impossible. You would need to touch the key to grant the sign request which would prevent any signing without you noticing.
It's more about the slippery slope of security vs convenience.
I do git rebase -i often. Do I want to touch my yubikey exactly 37 times for the 37 commits amended, or do I want to touch it once and just trust the software for the next N seconds to sign only these commits and not anything else?
Now, if I'm the verifier, do I trust the signer to do it properly? Or the half their commits are actually made by their cat and automatically signed?
Signing a tag is a relatively rare and very deliberate action. A more secure approach is less likely to impact convenience, reducing the chance of compromising security because it was inconvenient.