4 ms·

Any proof-of-software-certification blockchains out there? In which "mining" is a trusted party reviewing code & posting content integrity hashes of all derived

by jakear 4y ago

Any proof-of-software-certification blockchains out there? In which "mining" is a trusted party reviewing code & posting content integrity hashes of all derived bits. Then npm/pypi/cargo/whatever are given a list of the parties you trust and the number of certifications each bit needs before it can be downloaded. Edit: of all the responses, none provide any mechanism for the software-verifier to be compensated. Says a lot about how much we value that kind of work as an industry.

subharmonicon 4y ago
I’m not sure if they use blockchains per-se, but there are definitely companies that are trying to provide a secure software supply chain (chainguard is one I’m aware of, but I know nothing about the underlying technology).
- dlor 4y ago
  CEO here. We use a transparency log (sigstore) instead of a blockchain.
Beltalowda 4y ago
Not sure if you need anything as complex as that: just the Python tools recording the hash of the dependency and storing that in the git repo should be enough to prevent this particular problem. e.g. go.sum contains a hash of the entire source. I believe npm and cargo are similar. This way the user should always get the exact same dependency that I added as a developer, no matter what happens with their settings or connection or whatnot. Not familiar with Python's ecosystem at all, but judging from this commit[1] it doesn't seem to have anything it(?) [1]: https://github.com/pytorch/pytorch/commit/bc92444b34dfbe38419a1c8dbea9a7fc3284abe2 https://github.com/pytorch/pytorch/commit/bc92444b34dfbe3841...
- jakear 4y ago
  That protects this one avenue, but the more common one I've seen (npm land) is a compromised downstream dependency that gets automatically upgraded for whatever reason. Regardless - I want to be protected even when the Author of the package themselves is compromised (either by their tokens being stolen or them manually compromising the project)
- alexiaa 4y ago
  it does, but to use hashes you'd have to pin exact versions of every dependency, which is generally undesirable for a library
dlor 4y ago
Sigstore does this with a transparency log instead of a Blockchain.
dane-pgp 4y ago
> a trusted party reviewing code & posting content integrity hashes That sounds like some combination of Crev[0], Sigstore[1], and Trillian[2]. [0] https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/src/doc/getting_started.md https://github.com/crev-dev/cargo-crev/blob/master/cargo-cre... [1] https://docs.sigstore.dev/ https://docs.sigstore.dev/ [2] https://transparency.dev/ https://transparency.dev/
ashishbijlani 4y ago
Plug: I've been building Packj [1] to address exactly this problem. You can _audit_ as well as _sandbox_ installation of PyPI/NPM/Rubygems packages and flags hidden malware or "risky” code behavior such as spawning of shell, use of SSH keys, and mismatch of GitHub code vs packaged code (provenance). 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags malicious/risky packages.
Terretta 4y ago
We use https://www.kusari.dev/ https://www.kusari.dev/ which is about securing the building and deployment of software, not about blockchains. FRSCA: Factory for Repeatable Secure Creation of Artifacts provides a simple-to-install solution that aims to help secure the supply chain by building secure pipelines. It also provides abstractions and definitions with security guardrails ensuring all builds follow supply chain security best practices. GUAC: Graph for Understanding Artifact Composition leverages metadata to provide deeper visibility and enable users to quickly understand security issues throughout the software supply chain, their blast radius, and how to remediate their root causes. Learn more as we build this out in the open source with our blog article. https://www.kusari.dev/products/securesupplychain/ https://www.kusari.dev/products/securesupplychain/ See also: https://slsa.dev/ https://slsa.dev/
mkj 4y ago
A blockchain doesn't magically create money to pay the "miners". Well perhaps it might by taking money from speculators, but that isn't really a robust basis for security audits.
- jakear 4y ago
  The money comes from folks who want verified software and are willing to pay for it. The greatest failure of crypto thus far is convincing people it’s a speculators market. This had to happen when the only outcome of a mine was “a hash starting with a lot of 0’s and a couple hundred bytes we can all agree on”. Make mining produce something legitimately valuable and that is no longer necessary.
ameliaquining 4y ago
There's no technical fix for compensating verifiers; it has to be negotiated out of band. This is different from Bitcoin because the Bitcoin protocol is unambiguous, so any well-behaved node that follows it can trust that all other well-behaved nodes will accept its output as valid. By contrast, security review is inherently subjective and reasonable people will disagree, necessitating judgment calls on who to trust.
- jakear 4y ago
  Engineer the act of querying a trusted party to be a paid operation and the problem is solved. It doesn’t really matter if the verification is subjective, you pay 5 people you trust, only accept it if 4 say it’s good, and stop paying the 5th if they consistently disagree and/or vouch for disagreeable content.
deleted 4y ago
[deleted]
layer8 4y ago
Blockchain consensus only works when there are many more “verifiers” than there are items (blocks) to verify. Good luck with the amount of software updates being published and manual reviews. Regarding manually reviewing software, it would be very easy to create a malicious majority of verifiers who certify malware, because malicious “verification“ takes much less resources than truthful verification. Rather than verifiers being payed, verifiers would need to themselves pay for the right to verify, in order to throttle malicious “verification”. But realistically, you need verifiers that you trust in the first place, and if those exist, digital signatures are sufficient.

by jakear 4y ago

subharmonicon 4y ago

I’m not sure if they use blockchains per-se, but there are definitely companies that are trying to provide a secure software supply chain (chainguard is one I’m aware of, but I know nothing about the underlying technology).

dlor 4y ago
CEO here. We use a transparency log (sigstore) instead of a blockchain.

Beltalowda 4y ago

Not sure if you need anything as complex as that: just the Python tools recording the hash of the dependency and storing that in the git repo should be enough to prevent this particular problem. e.g. go.sum contains a hash of the entire source. I believe npm and cargo are similar. This way the user should always get the exact same dependency that I added as a developer, no matter what happens with their settings or connection or whatnot. Not familiar with Python's ecosystem at all, but judging from this commit[1] it doesn't seem to have anything it(?) [1]: https://github.com/pytorch/pytorch/commit/bc92444b34dfbe38419a1c8dbea9a7fc3284abe2 https://github.com/pytorch/pytorch/commit/bc92444b34dfbe3841...

jakear 4y ago
That protects this one avenue, but the more common one I've seen (npm land) is a compromised downstream dependency that gets automatically upgraded for whatever reason. Regardless - I want to be protected even when the Author of the package themselves is compromised (either by their tokens being stolen or them manually compromising the project)
alexiaa 4y ago
it does, but to use hashes you'd have to pin exact versions of every dependency, which is generally undesirable for a library

dlor 4y ago

Sigstore does this with a transparency log instead of a Blockchain.

dane-pgp 4y ago

> a trusted party reviewing code & posting content integrity hashes That sounds like some combination of Crev[0], Sigstore[1], and Trillian[2]. [0] https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/src/doc/getting_started.md https://github.com/crev-dev/cargo-crev/blob/master/cargo-cre... [1] https://docs.sigstore.dev/ https://docs.sigstore.dev/ [2] https://transparency.dev/ https://transparency.dev/

ashishbijlani 4y ago

Plug: I've been building Packj [1] to address exactly this problem. You can _audit_ as well as _sandbox_ installation of PyPI/NPM/Rubygems packages and flags hidden malware or "risky” code behavior such as spawning of shell, use of SSH keys, and mismatch of GitHub code vs packaged code (provenance). 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj flags malicious/risky packages.

Terretta 4y ago

We use https://www.kusari.dev/ https://www.kusari.dev/ which is about securing the building and deployment of software, not about blockchains. FRSCA: Factory for Repeatable Secure Creation of Artifacts provides a simple-to-install solution that aims to help secure the supply chain by building secure pipelines. It also provides abstractions and definitions with security guardrails ensuring all builds follow supply chain security best practices. GUAC: Graph for Understanding Artifact Composition leverages metadata to provide deeper visibility and enable users to quickly understand security issues throughout the software supply chain, their blast radius, and how to remediate their root causes. Learn more as we build this out in the open source with our blog article. https://www.kusari.dev/products/securesupplychain/ https://www.kusari.dev/products/securesupplychain/ See also: https://slsa.dev/ https://slsa.dev/

mkj 4y ago

A blockchain doesn't magically create money to pay the "miners". Well perhaps it might by taking money from speculators, but that isn't really a robust basis for security audits.

jakear 4y ago
The money comes from folks who want verified software and are willing to pay for it. The greatest failure of crypto thus far is convincing people it’s a speculators market. This had to happen when the only outcome of a mine was “a hash starting with a lot of 0’s and a couple hundred bytes we can all agree on”. Make mining produce something legitimately valuable and that is no longer necessary.

ameliaquining 4y ago

There's no technical fix for compensating verifiers; it has to be negotiated out of band. This is different from Bitcoin because the Bitcoin protocol is unambiguous, so any well-behaved node that follows it can trust that all other well-behaved nodes will accept its output as valid. By contrast, security review is inherently subjective and reasonable people will disagree, necessitating judgment calls on who to trust.

jakear 4y ago
Engineer the act of querying a trusted party to be a paid operation and the problem is solved. It doesn’t really matter if the verification is subjective, you pay 5 people you trust, only accept it if 4 say it’s good, and stop paying the 5th if they consistently disagree and/or vouch for disagreeable content.

deleted 4y ago

[deleted]

layer8 4y ago

Blockchain consensus only works when there are many more “verifiers” than there are items (blocks) to verify. Good luck with the amount of software updates being published and manual reviews. Regarding manually reviewing software, it would be very easy to create a malicious majority of verifiers who certify malware, because malicious “verification“ takes much less resources than truthful verification. Rather than verifiers being payed, verifiers would need to themselves pay for the right to verify, in order to throttle malicious “verification”. But realistically, you need verifiers that you trust in the first place, and if those exist, digital signatures are sufficient.