Feels way too over-engineered https://github.com/in-toto/specification/blob/v1.0/in-toto-s...
Taking the fun out of software engineering ...
They could have done better, though, by using XML!
In-toto: A framework to secure the integrity of software supply chains
11–20 of 20 posts
Re: In-toto: A framework to secure the integrity of software supply chains
#12Feels way too over-engineered https://github.com/in-toto/specification/blob/v1.0/in-toto-s...
Over engineering is really an NFR of green field projects.
Re: In-toto: A framework to secure the integrity of software supply chains
#13Feels way too over-engineered https://github.com/in-toto/specification/blob/v1.0/in-toto-s...
Sigstore?
Re: In-toto: A framework to secure the integrity of software supply chains
#14The issue with software supply chain is that you have to be in step the entire chain and developers are creative. I don’t have to pull in a dependency when I can copy paste code out of third party repos or stack overflow.
Also this doesn’t take into consideration one of the ugliest sides of SSC which is M&A. Sure on a completely greenfield piece of software, seems like it would be a solution (although over engineered tbh). But that doesn’t really exist in closed source systems as they are Frankenstein pieces of software that get new stuff bolted onto them.
Re: In-toto: A framework to secure the integrity of software supply chains
#15I thought this was a good explainer on what In-toto is, when to use it, and how it's different from e.g. Sigstore:
https://nesbitt.io/2026/05/24/signing-is-for-the-bad-days.ht...
Re: In-toto: A framework to secure the integrity of software supply chains
#16I've wondered with all the generated code, will llm provenance be a thing in the future? I can't imagine the DoD/DoW wants qwen writing its code.
Re: In-toto: A framework to secure the integrity of software supply chains
#17Earlier quoted context omitted.
That's exactly where I keep getting caught. I've looked at in-toto a number of times, and each time I've been left wondering "how is this better than a signed list of hashes?". Which I suppose is what in-toto is at its core, but it's taken me a long time and lots of reading to get to that point, and I'm not seeing the advantages of it (except it being a standard, OK, fair enough). I must be missing something.
I assume it is meant to not only have hashes of the final output, but also securely record all steps done by the right people and the right inputs during building of the software. But this solves the wrong^1 problems while still leaving the door open for malware. Reproducible builds are the right step forward if you actually care about security of free software ecosystem. 1. I guess this depend on your position. In t…
> In the context of remote attestation, I think this is also even dangerous / evil.
It's cool until it becomes enforced and we no longer hold the keys to our own hardware; bwim the ability to determine which key signers are to be trusted. But I don't think standing in the way of attestation tech is a fruitful tactic - much better to fight for hardware/key control.
Re: In-toto: A framework to secure the integrity of software supply chains
#18Earlier quoted context omitted.
I assume it is meant to not only have hashes of the final output, but also securely record all steps done by the right people and the right inputs during building of the software. But this solves the wrong^1 problems while still leaving the door open for malware. Reproducible builds are the right step forward if you actually care about security of free software ecosystem. 1. I guess this depend on your position. In t…
> In the context of remote attestation, I think this is also even dangerous / evil. It's cool until it becomes enforced and we no longer hold the keys to our own hardware; bwim the ability to determine which key signers are to be trusted. But I don't think standing in the way of attestation tech is a fruitful tactic - much better to fight for hardware/key control.
The website / service you want to use will not accept your key, but only the key from the organization that makes sure that your software does not make it possible to skip the ads. So I think the only chance to avoid this is to reject such concepts completely from the beginning.
Re: In-toto: A framework to secure the integrity of software supply chains
#19Earlier quoted context omitted.
> In the context of remote attestation, I think this is also even dangerous / evil. It's cool until it becomes enforced and we no longer hold the keys to our own hardware; bwim the ability to determine which key signers are to be trusted. But I don't think standing in the way of attestation tech is a fruitful tactic - much better to fight for hardware/key control.
The website / service you want to use will not accept your key, but only the key from the organization that makes sure that your software does not make it possible to skip the ads. So I think the only chance to avoid this is to reject such concepts completely from the beginning.
You can always build/compile your own software, having the local 'key' is the ability to do so. I'm not sure what else is implied - how will an external service / website enforce this?
Re: In-toto: A framework to secure the integrity of software supply chains
#20Earlier quoted context omitted.
The website / service you want to use will not accept your key, but only the key from the organization that makes sure that your software does not make it possible to skip the ads. So I think the only chance to avoid this is to reject such concepts completely from the beginning.
You can always build/compile your own software, having the local 'key' is the ability to do so. I'm not sure what else is implied - how will an external service / website enforce this?
Via remote attestation.