Rendered at 16:01:58 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fathermarz 23 minutes ago [-]
The 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.
Does Debian already provide signature on .deb files (that is, provide a manifest of their hashes and and sign each)? If so, you could potentially d/l the files from any source/mirror?
traceroute66 3 hours ago [-]
> Does Debian already provide signature on .deb files
Signing files is 90's security.
Yes, of course in 2026 it is still perfectly capable of proving a file has not been tampered with.
The problem is that is insufficient in 2026.
See the "Goals to protect against specific attacks" section[1] of TUF (The Update Framework) spec to give you an idea of modern attack vectors.
> Does Debian already provide signature on .deb files (that is, provide a manifest of their hashes and and sign each)?
Yes it does. If you look at https://ftp.debian.org/debian/dists/trixie/InRelease it's a PGP-signed file containing a list of files and their hashes. Each of those files (eg https://ftp.debian.org/debian/dists/trixie/main/binary-amd64...) then contains a list of .deb files along with their shasums. In other words, a Debian repo is a set of deb files, metadata files with their hashes, index files with hashes of the metadata files, and PGP signatures for the indexes, so the whole chain can be verified.
This means that anyone can set up a deb mirror by (essentially, there's some extra steps) copying that entire structure and the integrity is guaranteed because only the upstream admins can sign the metadata.
marksomnian 4 hours ago [-]
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.
uecker 4 hours ago [-]
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 the context of remote attestation, I think this is also even dangerous / evil.
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.
https://github.com/in-toto/specification/blob/v1.0/in-toto-s...
They could have done better, though, by using XML!
Does Debian already provide signature on .deb files (that is, provide a manifest of their hashes and and sign each)? If so, you could potentially d/l the files from any source/mirror?
Signing files is 90's security.
Yes, of course in 2026 it is still perfectly capable of proving a file has not been tampered with.
The problem is that is insufficient in 2026.
See the "Goals to protect against specific attacks" section[1] of TUF (The Update Framework) spec to give you an idea of modern attack vectors.
[1] https://theupdateframework.github.io/specification/v1.0.33/#...
> Does Debian already provide signature on .deb files (that is, provide a manifest of their hashes and and sign each)?
Yes it does. If you look at https://ftp.debian.org/debian/dists/trixie/InRelease it's a PGP-signed file containing a list of files and their hashes. Each of those files (eg https://ftp.debian.org/debian/dists/trixie/main/binary-amd64...) then contains a list of .deb files along with their shasums. In other words, a Debian repo is a set of deb files, metadata files with their hashes, index files with hashes of the metadata files, and PGP signatures for the indexes, so the whole chain can be verified.
This means that anyone can set up a deb mirror by (essentially, there's some extra steps) copying that entire structure and the integrity is guaranteed because only the upstream admins can sign the metadata.
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.
1. I guess this depend on your position. In the context of remote attestation, I think this is also even dangerous / evil.