Hacker News Reader

>This feels like this might actually be a use-case for a blockchain or a Merkle Tree.

A few years ago, a similar idea for firmware binary security[0] had been explored by Google as a possible application of their Trillian[1] distributed ledger, which is based on Merkle Trees.

I don't know if they've advanced adoption of Trillian for firmware, however, the website lists Go packaging[2], Certificate Transparency[3], and SigStore[4] as current applications.

[0] https://github.com/google/trillian-examples/tree/master/bina...

[1] https://transparency.dev/

[2] https://go.googlesource.com/proposal/+/master/design/25530-s...

[3] https://certificate.transparency.dev/

[4] https://www.sigstore.dev/

Sigstore artifact signature verification may be part of a SLSA secure software supply chain workflow.

slsa-framework/slsa-github-generator > Generate [signed] provenance metadata : https://github.com/slsa-framework/slsa-github-generator#gene... :

> Supply chain Levels for Software Artifacts, or SLSA (salsa), is a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises.

> SLSA defines an incrementally-adoptable set of levels which are defined in terms of increasing compliance and assurance. SLSA levels are like a common language to talk about how secure software, supply chains and their component parts really are.

Trillian was already the name for a distributed system - an instant-messaging app. I used to use it around a decade ago. Seems like they still exist, but have pivoted into enshittification (it's an Electron app now, and you have to buy a subscription for chat history and read receipts).

> One could use the 'strings' command to get detailed information about what files were used in a binary and which version! DVCS (git) broke that, so most people don't remember. [...]

> Consider: A file exists in a git repository under a hash, which theoretically (excluding hash collisions) uniquely identifies a file.

Git is of course incapable of including a file version number, as that’s not really well-defined in a distributed setting. But if you’re OK with a blob hash, put $Id$ in your source files, mark them with “ident” in .gitattributes, and you’ll see the hashes included and autoupdated on your next checkout[1]:

> When the attribute `ident` is set for a path, Git replaces $Id$ in the blob object with $Id:, followed by the 40-character hexadecimal blob object name, followed by a dollar sign $ upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in.

[1] https://git-scm.com/docs/gitattributes#_ident

How do you identify if log4j was one of your dependencies then? You'd just have a hash of the pom.xml or whatever and you'd still need a tool to check it.

edit: or do you mean that your hypothetical tool would generate the repository URLs + file hashes for its dependencies as well and bundle those with its own?

log4j is usually included as a binary component in a .jar file, so it should be obvious that it is a dependency. If you're using log4j with a remote logger, that's a configuration that probably wouldn't be captured by a hash. However, that fact that a specific version of log4j client library is included in your distribution should be easy to identify.

> Back in the day, we used to embed strings into the translation units that would report the original name and version of the file.

We still do this today. We rely on some tooling-added information and add our own custom information on top (git hash, hash of direct dependencies, compiler version and flags, etc).

> This feels like this might actually be a use-case for a blockchain or a Merkle Tree.

Merkle trees sure but you do not need a blockchain to store/manage hashes of sources and build products. Just have trustworthy parties attest that source commits yield particular binaries by their hashes and publish those signatures somewhere. Even Bitcoin Core does something like this using PGP.

The only reason for suggesting a block chain is that the information should be publicly available without having to visit a specific vendor's web site for confirmation.

But maybe it's not necessary.

DNS Root Zones, for example, are publicly accessible and well managed (maybe not the registrars, but the registry) so perhaps a well-funded third party could establish a trusted, global, registry for supply chain Merkle Trees.

> The compiler could even include into the binary the flags used to modify the compiler behavior.

There may be multiple sets of compiler flags and even multiple compilers (can there even be multiple linkers?)

In addition, having to pick between multiple functions called foo, a linker may pick either of them, and may not always pick the same one (parallel linkers often aren’t deterministic), even if their implementations are different.

There also is a decent chance you’ll have to document your OS, for example if the compiler dynamically links to a system library, or if the OS has FPU support in software, or if the OS tweaks some obscure CPU flags (and of course, you’ll have to document the specific CPU and CPU revision, as those can affect things like constant folding.

Re Merkle trees, that is what emerging IETF specific citations in the SCITT working group are about.

https://scitt.io/

Wouldn't that require also including the hash of every dynamic library in the system, the environment variables, configs etc, as all that can affect the resulting file ?

Isn't this exactly what Nix does?