It makes little sense to use web-of-trust to verify the identity of the committer and then accept whatever software they publish. GPG's web of trust makes sense because it's meant for communication, where "being from who it says" is the only form of trust that is wanted.
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.
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 v@depscheck.com 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.
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.
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.
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].
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.
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.
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 bar@google.com 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.
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.
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.
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
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.
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 nikolay@users.noreply.github.com 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.
Good "git" signature for [REDACTED] with ED25519 key SHA256:VqH020xxJ+XyDLBh99HuBjkdXye4xakUqE05dyDnZC8
fac93bd4295e 2022-06-08 | Some further updates (HEAD -> main) [Austin Ziegler]
[gpg]
format = ssh
[user]
signingKey = key::SSH-PUBKEY
In my case, since I have an ssh-ed25519 key, it is
[user]
signingKey = key::ssh-ed25519 AAAAC…
You can pretty much copy the `.pub` key and paste it after `key::` (instructions like the ones at https://calebhearth.com/sign-git-with-ssh will show this without the `key::` prefix; according to the latest git documentation, the non-prefixed SSH key format is not preferred, as the `signingKey` value can be either a raw SSH public key, a GPG key ID, or a path to the signing key).
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.
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?
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