Gitsign(blog.sigstore.dev)
blog.sigstore.dev
Gitsign
https://blog.sigstore.dev/introducing-gitsign-9fd3f1b682aa
42 comments
I agree with you that we need something different than trusting an entire user and everything that comes from them, and something more like trusting a specific releases.
I think crev is a step in the right direction, but there are some things I don't think they get right which makes it hard to actually be useful in practice. For example, there is no specifics regarding crew understanding files themselves, no easy way of aggregating data, the solution not being scalable for projects using lots of dependencies and some other points.
But rather than just complaining about crev, I've started to build an alternative, that addresses those issues. It's not really ready for showtime yet (it'll be a Show HN once it is :) ), but if this is something people want to help out and collaborate on, I'm happy to share the progress in private for now. If anyone is interested, reach out to me at [email protected] and we can talk more! I'm also currently looking for another full-time/part-time developer to work on the project together with me. Only requirement is some previous experience with Rust, Clojure and ClojureScript, and a burning desire of wanting to fix security in the open source packaging community.
I think crev is a step in the right direction, but there are some things I don't think they get right which makes it hard to actually be useful in practice. For example, there is no specifics regarding crew understanding files themselves, no easy way of aggregating data, the solution not being scalable for projects using lots of dependencies and some other points.
But rather than just complaining about crev, I've started to build an alternative, that addresses those issues. It's not really ready for showtime yet (it'll be a Show HN once it is :) ), but if this is something people want to help out and collaborate on, I'm happy to share the progress in private for now. If anyone is interested, reach out to me at [email protected] and we can talk more! I'm also currently looking for another full-time/part-time developer to work on the project together with me. Only requirement is some previous experience with Rust, Clojure and ClojureScript, and a burning desire of wanting to fix security in the open source packaging community.
Two more alternatives to crev:
https://github.com/vouch-dev/vouch
https://github.com/mozilla/cargo-vet
https://github.com/vouch-dev/vouch
https://github.com/mozilla/cargo-vet
Many thanks for sharing those! I hadn't seen them before, even though I was looking for other projects like cred.
If people know more related projects, I'd be more than happy to see them linked here too!
If people know more related projects, I'd be more than happy to see them linked here too!
Putting on my skeptical hat: what are commit signatures used for in the OSS community today, in practice? Do they prevent any supply chain attacks? Is forging a commit really an attractive strategy for an attacker? I assume the most form of verification is checking the github account/reputation.
I don't disagree. The current state of git signing is pretty bad. I wrote more here: https://link.medium.com/zqy8VVzAJqb
I'm a maintainer on gitsign and think we can fix it though!
I'm a maintainer on gitsign and think we can fix it though!
Thanks for pushing the state of the art on this. Personally I'm not a fan of git signatures either because they seem to pair something supposed to be permanent (a commit) to something supposed to be ephemeral (a signing key). (Distributed) ledger technology can absolutely improve the status quo here.
> what are commit signatures used for in the OSS community today
I'd like to think that when a package maintainer for a Linux distro downloads the latest version of the code they are packaging, they check that all the commits are signed by the same developer IDs as last time.
Okay, that's an over-simplification because you need to allow for key rotation, and new people joining the project, but that could be tractable or even automatable with a few heuristics and tools.
For example, there could be a tool for checking if new keys were signed by previous keys with the same email address, and there could be a contributors.policy file which specifies who the project leaders are and how many of them are needed to sign off on a given release or commit.
I'd like to think that when a package maintainer for a Linux distro downloads the latest version of the code they are packaging, they check that all the commits are signed by the same developer IDs as last time.
Okay, that's an over-simplification because you need to allow for key rotation, and new people joining the project, but that could be tractable or even automatable with a few heuristics and tools.
For example, there could be a tool for checking if new keys were signed by previous keys with the same email address, and there could be a contributors.policy file which specifies who the project leaders are and how many of them are needed to sign off on a given release or commit.
There was a case a while ago where the git server for a large project had been hacked and the maintainers had no way of knowing which commits were legitimate
I agree that this is a potentially huge problem, but I wouldn't say that they had "no way"; thanks to git's distributed natured, surely if N developers got together and verified that their local hashes match up to a certain commit, they could be reasonably sure that those are legitimate.
> I assume the most form of verification is checking the github account/reputation.
Did you mean to write "the most [used] form"? If so, it's unreliable. If you change your Git settings to use Torvals' email address, on GitHub it will show up as if your commits were made by his account[1].
[1]: <https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-co...>
Did you mean to write "the most [used] form"? If so, it's unreliable. If you change your Git settings to use Torvals' email address, on GitHub it will show up as if your commits were made by his account[1].
[1]: <https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-co...>
> Did you mean to write "the most [used] form"?
Yeah. Too late to edit.
I know that, but I postulate that people look at the author of the PR in githubs UI, not individual commits. Even if they did, the verified badge only points to a github profile anyway. So.. an attacker would much rather want to impersonate a github profile than a commit. I guess.
Yeah. Too late to edit.
I know that, but I postulate that people look at the author of the PR in githubs UI, not individual commits. Even if they did, the verified badge only points to a github profile anyway. So.. an attacker would much rather want to impersonate a github profile than a commit. I guess.
A malicious forged change in a CI/CD chain could cause problems.
Src: https://github.com/sigstore/gitsign
> Keyless Git signing with Sigstore!
> This is heavily inspired by [github/smimesign], but uses keyless Sigstore to sign Git commits with your own GitHub / OIDC identity
> Keyless Git signing with Sigstore!
> This is heavily inspired by [github/smimesign], but uses keyless Sigstore to sign Git commits with your own GitHub / OIDC identity
Don't jump in without reviewing the caveats:
* Not supported as "verified" in the GitHub UI [edit: mostly as opposed to "the main reason to try it"]
* A public transparency log "which may include user emails or repo identifiers"
* Not supported as "verified" in the GitHub UI [edit: mostly as opposed to "the main reason to try it"]
* A public transparency log "which may include user emails or repo identifiers"
I don't consider "verified" in the GitHub UI as safe to rely on.
If you forge a commit from Linus Torvalds, where Joe Blow is the co-author, as long as Joe Blow GPG signed the commit it will show "Verified" with no distinction indicating Linus did not.
This combined with other issues I reported to GitHub like this[0] ('working as intended', but now thankfully fixed because it blew up on Twitter months later) makes me think GitHub doesn't care to invest a whole lot in commit verification stuff.
[0] https://news.ycombinator.com/item?id=24977398
If you forge a commit from Linus Torvalds, where Joe Blow is the co-author, as long as Joe Blow GPG signed the commit it will show "Verified" with no distinction indicating Linus did not.
This combined with other issues I reported to GitHub like this[0] ('working as intended', but now thankfully fixed because it blew up on Twitter months later) makes me think GitHub doesn't care to invest a whole lot in commit verification stuff.
[0] https://news.ycombinator.com/item?id=24977398
I agree that GitHub "verified" does seem to be mostly for show right now, thanks for emphasizing that.
My point was more that the show (which many would consider using it for) isn't even working yet for this project.
My point was more that the show (which many would consider using it for) isn't even working yet for this project.
GitHub will only let you add a GPG key if you have verified your email address.
So, yes you can of course have Verified name spoofing, but at least the email in git commits can be trusted.
So, yes you can of course have Verified name spoofing, but at least the email in git commits can be trusted.
The "verified" checkmark in GitHub UI is not really a big reassurance. Someone can steal your private key, continue to use it and still be verified until you or someone else notices and revokes the key.
GitHub, for example, has their own GPG key as verified for commits you author on their UI. In this case, you're trusting GitHub –and GitHub can also mark sigstore certificates as verified as well (they should), as they're actually verifiable using a transparency log.
What sigstore really brings to the picture is the attestation of "whoever signed this commit was actually signed into the github account @foo –or google account [email protected] at the time, and here's the proof in a transparency log" –and those accounts can be secured by 2FA. It also takes you out of GPG key management business which I personally despise.
GitHub, for example, has their own GPG key as verified for commits you author on their UI. In this case, you're trusting GitHub –and GitHub can also mark sigstore certificates as verified as well (they should), as they're actually verifiable using a transparency log.
What sigstore really brings to the picture is the attestation of "whoever signed this commit was actually signed into the github account @foo –or google account [email protected] at the time, and here's the proof in a transparency log" –and those accounts can be secured by 2FA. It also takes you out of GPG key management business which I personally despise.
GitHub just needs support for SSH-based commit signing.
https://calebhearth.com/sign-git-with-ssh
https://calebhearth.com/sign-git-with-ssh
There is a discussion about the lack of support here -
(https://github.com/github-community/community/discussions/77... - released by end of June)
(https://github.com/github-community/community/discussions/77... - released by end of June)
We're working on fixes for both of those issues!
smimesign supports timestamping with a normal timestamp server, with a bit of extra effort. It would be cool if your tool could (at least optionally) do the same as an alternative to your custom transparency log.
https://github.com/github/smimesign/issues/47#issuecomment-4...
https://github.com/github/smimesign/issues/47#issuecomment-4...
We used to actually run an RFC3161 timestamp server in addition to the transparency log but recently turned it down because no one was using it. I'd like to bring it back for stuff like this.
https://github.com/sigstore/gitsign/issues/22
https://github.com/sigstore/gitsign/issues/22
I wrote a tool a long time ago to publish a tree of git sha's to a neat non-distributed pre-blockchain that was being supported by the Linux Foundation, https://publictimestamp.org
https://github.com/rektide/git-ts
Alas frigging publictimestamp.krg was a pretty basic site which was fully dynically rendered. Nine of web.archive.org leaves any evidence of what the public timestamping (centralized) blockchain was anymore. Terrible bitrot, ironically for a.project that was all about preserving histor That's a real bite in the ass by irony!
This was mostly for fun, because it was easy & made sense & I could havk it out in a weekend. I hope this project really does help us get good.
I keep thinking the missong element in so much of the shit we have- Certificate Transparency- is another feature. Signed Exchanges. When you https get a resource, a server shpuld cryptographically sign it, make the resource fungible. Http-signatures feom bag in the Google Buzz days had similar, but this is slicker & more capable. That way we can hold copies & swap them, & knoe, at one point yes, the host said this was true.
https://github.com/rektide/git-ts
Alas frigging publictimestamp.krg was a pretty basic site which was fully dynically rendered. Nine of web.archive.org leaves any evidence of what the public timestamping (centralized) blockchain was anymore. Terrible bitrot, ironically for a.project that was all about preserving histor That's a real bite in the ass by irony!
This was mostly for fun, because it was easy & made sense & I could havk it out in a weekend. I hope this project really does help us get good.
I keep thinking the missong element in so much of the shit we have- Certificate Transparency- is another feature. Signed Exchanges. When you https get a resource, a server shpuld cryptographically sign it, make the resource fungible. Http-signatures feom bag in the Google Buzz days had similar, but this is slicker & more capable. That way we can hold copies & swap them, & knoe, at one point yes, the host said this was true.
I'm excited to see this roll out but note the IMO important caveat here that GitHub does not currently show a gitsigned commit as "Verified".
Also, this is challenging to get working on a remote VM due to the auth process. My understanding is there is work under way to sort this out.
Also, this is challenging to get working on a remote VM due to the auth process. My understanding is there is work under way to sort this out.
We're working on a GitHub App to work around the badge issue - it will also let you specify fine-grained policies instead of just signed or unsigned.
The tty issue on remote VMs is also getting fixed soon!
Disclosure: I work on Sigstore.
The tty issue on remote VMs is also getting fixed soon!
Disclosure: I work on Sigstore.
This tool would be great for making sure that unauthorized users should not be changing the supply chain for users of git. But, what this won’t do is solving the problem of authorized users intentionally breaking software. A solution for that would be for you to audit what software you are including and not mindlessly updating software. Also, checking hashes of what you are pulling from an external source or even hosting a package repository yourself.
My issue with S/MIME is that (unless you use GitHub's smimesign) I cannot use [email protected] fake email - my actual Actalis S/MIME certificate reveals my email, so, I can't use it to sign with git. I wish the fake GitHub email had a feature to show you the email received in the last 15 minutes at the no-reply email!
Balancing privacy vs transparency is definitely something that's tricky! You may be interested in https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 which goes into some of the background of why email addresses are used and some of the things we're thinking about in this area for Sigstore.
Disclosure: I'm the creator of gitsign and wrote this blog post.
Disclosure: I'm the creator of gitsign and wrote this blog post.
Git commits can be signed with SSH keys now:
https://twitter.com/damienmiller/status/1531502392457723905 (thread)
https://twitter.com/damienmiller/status/1531502392457723905 (thread)
Unfortunately, this doesn't work with 1Pasword for SSH.
Fortunately, it does work with 1Password for SSH.
Good "git" signature for [REDACTED] with ED25519 key SHA256:VqH020xxJ+XyDLBh99HuBjkdXye4xakUqE05dyDnZC8
fac93bd4295e 2022-06-08 | Some further updates (HEAD -> main) [Austin Ziegler]I can't make it work as it complains about the format of the signing key. Can you please share your setup? Thanks!
Sorry, I had missed this.
The format is
One thing of note that I haven’t checked to see if it matters. I have the matching `.pub` key in `~/.ssh`, but I don’t think that is making a difference.
I do remember having some struggles getting it sorted out at the very beginning, but I didn’t take very good notes of what different things I tried.
The format is
[gpg]
format = ssh
[user]
signingKey = key::SSH-PUBKEY
[user]
signingKey = key::ssh-ed25519 AAAAC…
One thing of note that I haven’t checked to see if it matters. I have the matching `.pub` key in `~/.ssh`, but I don’t think that is making a difference.
I do remember having some struggles getting it sorted out at the very beginning, but I didn’t take very good notes of what different things I tried.
[deleted]
Thank you!
Afaik 1Password simply provides an ssh-agent. So I don‘t see why this should not work.
If you set gits user.signingKey to your public key and have SSH_AUTH_SOCk point to 1password agent this should work. Do you have any details on why not?
[deleted]
Looks great, it's a shame GitHub doesn't recognize it yet.
It makes a lot more sense to use web-of-trust to verify that releases are not malicious directly. This is what crev [1] does and I can't wait to see adoption in more package ecosystems.
Trusting yourcolleague42 who trusts that 'left-pad was made by steve' doesn't prevent steve from publishing a malicious release, even if GitHub can check steve's signatures on his releases and commits.
Trusting yourcolleague42 who trusts that 'left-pad 1.2.3 with hash abc1234fde is safe' removes all of the risk.
[1]: https://github.com/crev-dev