bishopNov 8, 2023
Matthew Garrett
Anyone out there at GitHub: could you please add support for adding an SSH CA key to a repo and then enforcing that commits be signed with a certificate signed by that CA? This is already supported in git, and would let orgs just upload their CA and enforce signatures without needing to manage keys for individual users.
Nov 8, 2023 at 6:13pmWeb
Show threadChar has movedNov 8, 2023
@mjg59
Looks like a self-hosted Gitlab could handle it and it's marked the SaaS should too. I know gpg key signing is well supported by gitlab. https://docs.gitlab.com/ee/user/project/repository/signed_commits/x509.html
Sign commits and tags with X.509 certificates | GitLab

GitLab product documentation.

Show threadMatthew GarrettNov 8, 2023
@Char that only seems to support x509 and gpg, not ssh
Show threadChar has movedNov 8, 2023
@mjg59
Yes. It would be convoluted converting gpg to/from ssh but possible. Although, if your goal is to have a single CA trust, you'll still have some need to manage individual user certificates. At some point might be easier distributing yubikey/nitrokey or similar.
Show threadMatthew GarrettNov 8, 2023
@Char I have SSH certificates, gpg is absolutely a non-starter here
Show threadKevin JonesNov 8, 2023
@mjg59 I've been thinking a lot about things to improve here - no timelines or concrete ideas, but this space occupies a non-empty part of my brain.
Show threadEric SampsonNov 23, 2023
@vcsjones @mjg59 I’m glad you’re at GH, Kevin
Show threadJames Just JamesNov 8, 2023
@mjg59 If a company did this, and an engineer left the company, and then they changed the cert, would this break all historical verification?
Show threadMatthew GarrettNov 8, 2023
@purpleidea verification is already a one shot because it needs to be marked verified even if the cert expired later
Show threadJames Just JamesNov 8, 2023

@mjg59 So if companies use this it's fine because GitHub performs and then stores that verification flag once on push, but say for anyone else down the road not using GitHub, it would not verify correctly if they didn't check when the cert still had that user in...

Am I understanding that right?

Show threadMatthew GarrettNov 8, 2023
@purpleidea Eh not really - the cert is in the signature so if you have a reason to trust the cert you can independently verify that at any time
Show threadLucas GarronNov 8, 2023
@mjg59 @vcsjones might know the state of things!
Show threadMark PhippardNov 8, 2023
@mjg59 you can do this at the GitHub organization level https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities
About SSH certificate authorities - GitHub Enterprise Cloud Docs

With an SSH certificate authority, your organization or enterprise account can provide SSH certificates that members can use to access your resources with Git.

GitHub Docs
Show threadMegNov 8, 2023
@markphip @mjg59 only in GitHub Enterprise afaik? They consider it a paywalled enterprise feature that the plebs would never want I think.
Show threadMatthew GarrettNov 8, 2023
@markphip that enforces certificates for auth, not for signing
Show threadrobrykNov 8, 2023
@mjg59
How does that support in git handle expiry?
Show threadMatthew GarrettNov 8, 2023
@robryk what do you mean?
Show threadrobrykNov 8, 2023

@mjg59

SSH certs can expire. What should happen if a commit is signed with a key that had an expiring cert attached? Should we outright reject it (because the signature will become "invalid" for some meaning thereof in the future), accept if it's valid now, accept if it's valid at its stated commit time (and maybe enforce that commits are younger than their parents), or something else?

Show threadrobrykNov 8, 2023
@mjg59 Now that I think of this some more, I wonder whether it would make sense to have a way to specify rules like "every commit has to be signed in a way that satisfies <foo> or has to be an ancestor of commit <bar>", so that one can do effective rotations of signing keys while not having to trust the repo storage to do all the verification (i.e. while allowing the same verification to happen when e.g. cloning).
Show threadMatthew GarrettNov 8, 2023
@robryk oh I see - got just calls out to SSH to handle this
Show threadrobrykNov 8, 2023

@mjg59

That has a weird effect where you cannot repush a commit that was there already, if it got gced in the meantime, and where e.g. accepting a pull request might work differently depending where the source branch is (because it either does or does not involve adding the commits).