7 ms·

Gitsign

104 points by semiquaver 4y ago

rektide 4y ago
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://publictimestamp.org https://github.com/rektide/git-ts 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.
westurner 4y ago
Src: https://github.com/sigstore/gitsign 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
newman314 4y ago
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.
- dlor 4y ago
  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.
password4321 4y ago
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"
- judge2020 4y ago
  GitHub just needs support for SSH-based commit signing. https://calebhearth.com/sign-git-with-ssh https://calebhearth.com/sign-git-with-ssh
  - icansearch 4y ago
    There is a discussion about the lack of support here - (https://github.com/github-community/community/discussions/7744#discussioncomment-2880682 https://github.com/github-community/community/discussions/77... - released by end of June)
- dlor 4y ago
  We're working on fixes for both of those issues!
  - password4321 4y ago
    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-466047139 https://github.com/github/smimesign/issues/47#issuecomment-4...
    - dlor 4y ago
      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
klabb3 4y ago
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.
- yarg 4y ago
  A malicious forged change in a CI/CD chain could cause problems.
- dane-pgp 4y ago
  > 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.
- Gigachad 4y ago
  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
  - gspr 4y ago
    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.
    - 4y ago
yavor 4y ago
Looks great, it's a shame GitHub doesn't recognize it yet.
zitterbewegung 4y ago
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.
foodstances 4y ago
Git commits can be signed with SSH keys now: https://twitter.com/damienmiller/status/1531502392457723905 https://twitter.com/damienmiller/status/1531502392457723905 (thread)
- nikolay 4y ago
  Unfortunately, this doesn't work with 1Pasword for SSH.
  - fstelzer 4y ago
    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 4y ago
      [deleted]
  - halostatue 4y ago
    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]
    - nikolay 4y ago
      Thank you!
    - deleted 4y ago
      [deleted]
    - nikolay 4y ago
      I can't make it work as it complains about the format of the signing key. Can you please share your setup? Thanks!
nikolay 4y ago
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!
- wlynch 4y ago
  Balancing privacy vs transparency is definitely something that's tricky! You may be interested in https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 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.
remram 4y ago
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. [1]: https://github.com/crev-dev https://github.com/crev-dev
- diggan 4y ago
  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.
  - rndhouse 4y ago
    Two more alternatives to crev: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet

104 points by semiquaver 4y ago

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://publictimestamp.org https://github.com/rektide/git-ts 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.

westurner 4y ago

Src: https://github.com/sigstore/gitsign 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

newman314 4y ago

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.

dlor 4y ago
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.

password4321 4y ago

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"

judge2020 4y ago
GitHub just needs support for SSH-based commit signing. https://calebhearth.com/sign-git-with-ssh https://calebhearth.com/sign-git-with-ssh
- icansearch 4y ago
  There is a discussion about the lack of support here - (https://github.com/github-community/community/discussions/7744#discussioncomment-2880682 https://github.com/github-community/community/discussions/77... - released by end of June)
dlor 4y ago
We're working on fixes for both of those issues!
- password4321 4y ago
  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-466047139 https://github.com/github/smimesign/issues/47#issuecomment-4...
  - dlor 4y ago
    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

klabb3 4y ago

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.

yarg 4y ago
A malicious forged change in a CI/CD chain could cause problems.
dane-pgp 4y ago
> 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.
Gigachad 4y ago
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
- gspr 4y ago
  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.
  - 4y ago

yavor 4y ago

Looks great, it's a shame GitHub doesn't recognize it yet.

zitterbewegung 4y ago

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.

foodstances 4y ago

Git commits can be signed with SSH keys now: https://twitter.com/damienmiller/status/1531502392457723905 https://twitter.com/damienmiller/status/1531502392457723905 (thread)

nikolay 4y ago
Unfortunately, this doesn't work with 1Pasword for SSH.
- fstelzer 4y ago
  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 4y ago
    [deleted]
- halostatue 4y ago
  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]
  - nikolay 4y ago
    Thank you!
  - deleted 4y ago
    [deleted]
  - nikolay 4y ago
    I can't make it work as it complains about the format of the signing key. Can you please share your setup? Thanks!

nikolay 4y ago

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!

wlynch 4y ago
Balancing privacy vs transparency is definitely something that's tricky! You may be interested in https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 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.

remram 4y ago

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. [1]: https://github.com/crev-dev https://github.com/crev-dev

diggan 4y ago
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.
- rndhouse 4y ago
  Two more alternatives to crev: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet