4 ms·

> "Is this software trustworthy?" becomes almost identical to "Is the set of people who wrote and reviewed this software trustworthy?" Yes! Simply being able t

by dlor 5y ago

> "Is this software trustworthy?" becomes almost identical to "Is the set of people who wrote and reviewed this software trustworthy?" Yes! Simply being able to trace an artifact back to the set of people who wrote and reviewed it would be a major win over where we are today. Disclosure: I'm a lead on this and a bunch of other supply chain security projects at Google.

jonahbenton 5y ago
As someone who spent a bunch of time with open source Grafeas early in its life around supply chain issues I am wondering- do those bits play a role in this infrastructure, or have they been supplanted?
- dlor 5y ago
  In my head Grafeas does two things: provide a data schema, and a data store. I think they both still have some value, but the schema is probably more interesting to me at this point.
deleted 5y ago
[deleted]
er4hn 5y ago
I would love to hear your thoughts on the problems with signing every commit. To be honest, I'm surprised it didn't make the initial level 1 -> 4 list since git gets you a lot of the way there. In my own employers threat model that ranked pretty highly and I wrote about our own experiences here: https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ https://eos.arista.com/commit-signing-with-git-at-enterprise... . With perspective I would say that the biggest thing I would add onto this is support for RFC 3161 style signed timestamps to the commit, but otherwise this solves a major issue.
- dlor 5y ago
  You're pretty much spot on. The problem is less about signing and more about existing PKI for git commit signing. We're working with David Huseby to help refactor the way gpg is coupled with git to enable stronger/different PKIs: https://github.com/TrustFrame/git-cryptography-protocol https://github.com/TrustFrame/git-cryptography-protocol I always personally struggle to recommend signing when it's so hard to do correctly. Until there's actually something workable, that supports time-stamping like you mentioned it seems like a false sense of security at best.
  - er4hn 5y ago
    Thanks for sharing this. This is very interesting and I did not know about it. I'll make a note to read it and see if there are any useful contributions I can make.
- thayne 5y ago
  One big problem is how to deal with a key getting revoked. That means every commit signed with that key is no longer valid. As I understand it, re-signing the commits requires rewriting git history, and would probably be a huge pain even if it didn't.
  - er4hn 5y ago
    That's what having a trustworthy timestamp solves. A key is revoked at a known time, so being able to know if a commit was signed before or after the time of revocation lets you know what the key to use to validate should be. If you don't have trusted timestamps it is a little harder to trust the git commit timestamps. Those can be altered and you need to add additional checks like comparing with what your code review service says (which can be altered..) or requiring that timestamps increase for each commit (which has edge cases..)

by dlor 5y ago

jonahbenton 5y ago

As someone who spent a bunch of time with open source Grafeas early in its life around supply chain issues I am wondering- do those bits play a role in this infrastructure, or have they been supplanted?

dlor 5y ago
In my head Grafeas does two things: provide a data schema, and a data store. I think they both still have some value, but the schema is probably more interesting to me at this point.

deleted 5y ago

[deleted]

er4hn 5y ago

I would love to hear your thoughts on the problems with signing every commit. To be honest, I'm surprised it didn't make the initial level 1 -> 4 list since git gets you a lot of the way there. In my own employers threat model that ranked pretty highly and I wrote about our own experiences here: https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ https://eos.arista.com/commit-signing-with-git-at-enterprise... . With perspective I would say that the biggest thing I would add onto this is support for RFC 3161 style signed timestamps to the commit, but otherwise this solves a major issue.

dlor 5y ago
You're pretty much spot on. The problem is less about signing and more about existing PKI for git commit signing. We're working with David Huseby to help refactor the way gpg is coupled with git to enable stronger/different PKIs: https://github.com/TrustFrame/git-cryptography-protocol https://github.com/TrustFrame/git-cryptography-protocol I always personally struggle to recommend signing when it's so hard to do correctly. Until there's actually something workable, that supports time-stamping like you mentioned it seems like a false sense of security at best.
- er4hn 5y ago
  Thanks for sharing this. This is very interesting and I did not know about it. I'll make a note to read it and see if there are any useful contributions I can make.
thayne 5y ago
One big problem is how to deal with a key getting revoked. That means every commit signed with that key is no longer valid. As I understand it, re-signing the commits requires rewriting git history, and would probably be a huge pain even if it didn't.
- er4hn 5y ago
  That's what having a trustworthy timestamp solves. A key is revoked at a known time, so being able to know if a commit was signed before or after the time of revocation lets you know what the key to use to validate should be. If you don't have trusted timestamps it is a little harder to trust the git commit timestamps. Those can be altered and you need to add additional checks like comparing with what your code review service says (which can be altered..) or requiring that timestamps increase for each commit (which has edge cases..)