9 ms·
Signing Git commits with your SSH key (2021)
- tejtm 4y agoDon't think I am the use case here. I have zero hesitancy to blow away a git ssh key for any reason and use different keys from different hosts which are not used for anything else. Entangling an ephemeral key as a supposedly permanent signature would have to be for things I had no long term commitment to.
- nomel 4y ago> I have zero hesitancy to blow away a git ssh key for any reason and use different keys from different hosts which are not used for anything else. I'm a little confused. I thought this was how you're supposed to do it, so you can easily revoke access for a particular host.
- denkmoon 4y agoGenerally yes, but here you're using this ostensibly ephemeral key as an identity. Usually you want your identity to _not_ be ephemeral, so that it can reliably identify you. Which is why this is a bit silly and I don't see why you'd do this rather than "good old" PGP.
- justsomeadvice0 4y agoLots of people use permanent-ish HSM-backed keys (like yubikeys) for SSH access so I guess this saves them from distributing another key? Outside of that I agree, I don't really see the point.
- stormbrew 4y agoMostly because using pgp (or more specifically gpg) is a pain in the ass and ssh-keygen is not
- wodenokoto 4y agoI can setup a pair of SSH keys. I have given up trying to setup PGP. So that's one reason to not use ""good old" PGP". Why can a PGP key be permanent but an SSH key not? I'm assuming both are just files and as a user you are required not to lose/give them away.
- trissylegs 4y agoI think you should be signing with a different key than your push/pull key. It's just so you don't have to use GPG when key signing is required.
- _alex_ 4y agoif you sign your commits, you should also consider timestamping your commits. I use OpenTimestamps for this. Docs and some rationale here: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md https://github.com/opentimestamps/opentimestamps-client/blob... from the doc: > My signing keys (e.g. blog or Qubes code signing keys) do not have expiration dates. This is not laziness. There is a fundamental problem with using an expiration date on keys used for code signing (e.g. git tag -s), because it is unclear what the outcome should be when one verifies some old code (written and signed when the key was still valid) in the future when the key has already expired? > Naturally we would like the old code, written and signed when the key was still valid, to continue to verify fine also in the future, after the key expires (and the developer passed away, perhaps). However, it is very problematic to prevent the attacker from creating falsified code pretending to be an old one.
- justsomeadvice0 4y agoAlright I'll bite - why do all this blockchain hoopla instead of just using SMIME/CMS's trusted timestamp feature? That already works fine with git signatures.
- andrewstuart2 4y agoPersonally I'm pretty against bitcoin et all for their wastefulness (PoW) or lack of improvement on existing systems (PoS), but I can definitely see trusted timestamps as a valid use of a public ledger. Ironically, since git is implemented as a merkle tree, you could do this quite easily in git as a "blockchain" minus the Proof of *. So, no distributed trust, but I'm personally usually glad to trade a little bit of centralization for a whole lot of performance/efficiency.
- justsomeadvice0 4y agoWe are on the same page. I do think there are some gains, although I question the use of "permissionless" blockchains (we have to remember to add this caveat now since we decided 90s tech should now be called "permissioned blockchains"). A simple published ledger ("immutable append-only", like CT logs) seems like a much easier route. If nodes care enough, they can poll it and alert when the tip changes in a way that should not be allowed.
- whitepirate20 4y agoThis is nice. At my company, some “bad actors” were pushing commits to git repositories that impersonated a bunch of employees at the company to repos that were essentially targeted hate crimes. I definitely recommend something like this.
- nonethewiser 4y agoCommits such as?
- wyldfire 4y agocommit 3c2f202543b31e9d7e2fff92a211a0f37ebcca9b (HEAD -> master) Author: Dave <dave@meanco.com> Date: Tue Sep 13 21:32:41 2022 -0500 I am not smart.
- waynesonfire 4y ago
- whitepirate20 4y agoJust code contributions to some trans hating repo or something, don’t remember the details.
- nukemandan 4y agohttps://github.com/jayphelps/git-blame-someone-else https://github.com/jayphelps/git-blame-someone-else
- wyldfire 4y agoNote that signing commits doesn't bar bad actors from pushing unsigned commits with forged identities. Also note that until you can individually get the good actors' public key you can't verify their commits. So it's not enough to distribute the instructions in this webpage, you also have to have a trusted key exchange. Everyone who wants to verify commits will need a copy of everyone who might sign commits' public keys. If you trust github then you can use them as a key broker like the "User SSH Keys from GitHub" section suggests, if all of your committers are github users.
- swlkr 4y agoI love this, GPG has always been really foreign to me. I still got the hang of it to verify my commits on github.
- gspr 4y agoThankfully, an alternative PGP implementation is quickly gaining traction: https://sequoia-pgp.org/ https://sequoia-pgp.org/
- gaius_baltar 4y agoThis seems to me a fundamentally bad idea: signing commits should be a "long lived" thing, but using an infrastructure designed for easily replaceable authentication (ie: add your pub keys to servers and remove/replace/destroy them at the very minimal suspicion of the private keys being compromised). And all the non-existing certification infrastructure (the article proposes one; we can end up with multiple incompatible signing/certification systems, none of them with the reach of existing OpenPGP). And at last, but not least, putting too many eggs in the same basket.
- deleted 4y ago[deleted]
- stingraycharles 4y agoIt’s better than not signing at all, though, which appears to be the current status quo. You can also sign with a different key than your “regular” ssh key(s), and as such reduce the chance you’ll have to replace them. Having said that, key rotation and distribution is obviously better with GPG, and I personally have been using that for years.
- wongarsu 4y agoCommit signing with S/MIME also works great. The downside is that you have to buy an "email" S/MIME cert from one of the usual cert gatekeepers for a couple dollars, but in return anyone can verify the signatures without exchanging public keys with me (or building a web of trust), and expiration and revocation are solved problems (including verifying signatures made with keys that are now expired, which seems not really supported with SSH keys)
- wlynch 4y agoYou may want to check out https://github.com/sigstore/gitsign https://github.com/sigstore/gitsign! You can generate ephemeral x509 code signing certs for free using Sigstore. (disclosure: I'm a maintainer for gitsign)
- sowbug 4y agoI can ssh (of course) with my ssh key, and now I can sign Git commits with it. Can I also use an ssh key for encryption? My keys are all ed25519 if that helps. I see a few proofs of concept on the web, but nothing as easy* as gpg. My only use case for gpg asymmetric encryption is encrypting my offsite backups, and various small things. In other words, I encrypt only to myself, and I like asymmetric encryption because I can keep the private key offline. *that word is used ironically. gnupg is the devil I know, so I don't mind it much these days, but I'd love to migrate off it completely.
- nixgeek 4y agoYes, this is incredibly easy to use: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- sowbug 4y agoAh, I'd forgotten that age can use SSH keys. Thanks!
- lrvick 4y agoGnupg is shit but PGP itself is just fine and we recently have more modern and well tested implementations of it now like https://sequoia-pgp.org/ https://sequoia-pgp.org/
- conaclos 4y agoThe sq program is not stable yet. right?
- lrvick 4y agoNo, but it is way more tested and stable than GnuPG imo. That said limited smartcard support keeps me from using it yet, but that is in testing and rapidly maturing.
- Toreno96 4y agoWow, it seems promising. Did you have a chance to use their CLI? Is it indeed better (more intuitive, less complex, more idiot-proof) than the GnuPG one?
- password4321 4y agoHOWTO for 1Password for SSH https://news.ycombinator.com/item?id=31686511#31777365 https://news.ycombinator.com/item?id=31686511#31777365
- gorgoiler 4y agoNice, if you have a distributed project. If you work in a commercial environment with an authenticated central repository then all actions are logged. This is the best place to audit who-did-what. I suppose this doesn’t work though if you have developers with legitimate reasons to push commits by other people. What would those be? Cherry picking bug fixes to a release branch? One engineer merging a branch where they’ve been collaborating with someone else? I would probably want to take ownership of the former, and the latter isn’t very common now in the era of “everything on master”.
- larusso 4y agoI tried to replace gpg with this setup last year and failed because I wanted to use FIDO2 ssh keys which are stored on a yubikey. It didn't work back then. My hope was that I could get to a setup where I only need a yubikey and the gitconfig to make this work. I stayed with gpg signing for now since my key is on the same yubikey as the ssh key now. Does this work now? On that note I really like the FIDO ssh feature but would like to see more services support these. Arch User Repository still doesn't support these and I don't know what the status over at gitlab is now.
- noman-land 4y agoI sign commits with a pgp key on a yubikey and also use it for ssh. Check out gpg-agent. It works!
- larusso 4y agoThis is not what I meant. I used this setup before. But you need gpg, the right config, the ssh-agent from gpg etc. I did a setup like this on macOS, Linux, and windows. It was a nightmare to setup. MacOS starts an ssh-agent by default so one needs to rewrite the environment etc to inject gpg ssh-agent. Linux is a little simpler though. What I wanted is to use the external ssh keys on a Fido key [1] in combination with the commit signing feature. With that I would skip the whole gpg part of the setup and only configure git and maybe ssh. But the generated keys (they have a -sk postfix) didn’t work with the signing feature. https://fido.ftsafe.com/open-ssh-with-fido-keys/ https://fido.ftsafe.com/open-ssh-with-fido-keys/
- larusso 4y agoAnd don’t get me started on windows and WSL. WSL has no access to USB. And there are no device pipes only file pipes. There is a solution for this with a custom process on windows which passes the Fido key over a file pipe/socket (not sure about the specifics anymore). There was no on click setup at the time when I did this. Maybe that has changed.
- smileybarry 4y ago
- moffkalast 4y agoSigning Git commits with your SSH key, and other pointless things you can waste your time on.
- vsnf 4y agoTo summarize the comments in this thread so far... * Signing your commits is a waste of time * Signing your commits with SSH keys is bad because it conflates an ephemeral key with a permanent identity * Signing your commits with anything but GPG isn't worth it The first point is hard to argue against because the commenters who offered the opinion didn't give many details to understand their perspective. The second, which is the most common sentiment so far, seems to be because people misunderstand that it doesn't have to be your push/pull key. It can be any SSH key, including a special-purpose key whose only job is to be held securely and act as a signing key. And the third kind of suffers the same problem as the first -- not enough details are given to understand.
- planede 4y agoIf the key is only used for signing, then why an SSH key?
- anotherhue 4y agobecause the ssh-keygen UI is considerably easier and likely more familiar than gpg. I shouldn't have to know what ElGamel is to sign a commit.
- sph 4y agoI have a pretty decent security setup (password manager, multiple SSH identities, OTP 2FA, Yubikeys) but GPG is such a usability nightmare I don't want to touch it with a 10 foot pole.
- account42 4y agoThat still doesn't answer why this needs to be solved by added SSH signing format to git (which everything in the ecosystem needs to adapt to) instead of creating a better gpg-keygen.
- joshmanders 4y ago> I shouldn't have to know what ElGamel is to sign a commit. I use gpg to sign my commits, it was as easy to setup as git ssh keys were... I don't know what ElGamel is either.
- aborsy 4y agoSSH is a secure shell protocol. You should rotate your keys as much as possible. Why using it outside its context? I use an ed25519 GPG key secured in a hardware security key. It’s convenient and secure. My SSH keys are ephemeral as much as possible.
- ekianjo 4y agoYou dont have to use the same ssh key you use to connect to a server. A ssh key can be created for just any purpose.
- aborsy 4y agoPublic key cryptography is used in many applications. What’s the motivation for using encryption tools in a transport protocol for signing data or documents? It’s not a full solution, and makes the SSH code base larger, and harder to maintain. GPG has key management tools and various functionalities around signing. Minisign is another clean tool to watch for.
- exabrial 4y agoPlease just use pgp. You need expiration, permissible purpose, revocation, identity, etc embedded into a ‘key’. Pgp is really really good at doing these things and has been though the ringer on security. Yes pgp sucks at its original Purpose (encrypting email) but it’s excellent for signing things.
- waynecochran 4y agoIs there a particular implementation of PGP that folks should use?
- exabrial 4y agoGPG is available nearly everywhere on every platform. If you're on OSX you can install MacGpg which provides a nice UI.
- RunSet 4y agoI find that requiring signed git commits is extremely useful for metric-chasing github repo owners who can use it to justify claiming credit for bugfixes that I submitted but did not sign.