6 ms·

Back in the day, we used to embed strings into the translation units that would report the original name and version of the file. One could use the 'strings' c

Back in the day, we used to embed strings into the translation units that would report the original name and version of the file. 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. Knowing know which version of a file made it into a binary still doesn't really help you, though. The compiler used (if any), the version of the compiler and linker, and even the settings / flags used affect the output and -- in some cases -- could convert an otherwise secure program into something exploitable. A Software BoM sounds like a "first step" towards documenting a supply chain, but I'm not sure it's in the right direction. This feels like this might actually be a use-case for a blockchain or a Merkle Tree. Consider: A file exists in a git repository under a hash, which theoretically (excluding hash collisions) uniquely identifies a file. Embed the file hashes in the executable along with a repository URL and you essentially know which files were used to build a file. Sign the executable to ensure it's not tampered with, then upload the hash of the executable to a block chain. If your executable is a compiler, then when someone else builds an executable then they can embed the hash of the compiler into the executable to link the binary back to the specific compiler build that made the binary. The compiler could even include into the binary the flags used to modify the compiler behavior.

616c 3y ago
Re Merkle trees, that is what emerging IETF specific citations in the SCITT working group are about. https://scitt.io/ https://scitt.io/
dj_mc_merlin 3y ago
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?
- c-linkage 3y ago
  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.
  - deleted 3y ago
    [deleted]
jjnoakes 3y ago
> 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).
treyd 3y ago
> 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.
- c-linkage 3y ago
  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.
evanjrowley 3y ago
>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/binary_transparency/firmware https://github.com/google/trillian-examples/tree/master/bina... [1] https://transparency.dev/ https://transparency.dev/ [2] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md https://go.googlesource.com/proposal/+/master/design/25530-s... [3] https://certificate.transparency.dev/ https://certificate.transparency.dev/ [4] https://www.sigstore.dev/ https://www.sigstore.dev/
- westurner 3y ago
  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#generate-provenance 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.
- LoganDark 3y ago
  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).
sega_sai 3y ago
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 ?
Someone 3y ago
> 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.
mananaysiempre 3y ago
> 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 https://git-scm.com/docs/gitattributes#_ident
endgame 3y ago
Isn't this exactly what Nix does?

616c 3y ago

Re Merkle trees, that is what emerging IETF specific citations in the SCITT working group are about. https://scitt.io/ https://scitt.io/

dj_mc_merlin 3y ago

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?

c-linkage 3y ago
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.
- deleted 3y ago
  [deleted]

jjnoakes 3y ago

> 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).

treyd 3y ago

> 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.

c-linkage 3y ago
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.

evanjrowley 3y ago

>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/binary_transparency/firmware https://github.com/google/trillian-examples/tree/master/bina... [1] https://transparency.dev/ https://transparency.dev/ [2] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md https://go.googlesource.com/proposal/+/master/design/25530-s... [3] https://certificate.transparency.dev/ https://certificate.transparency.dev/ [4] https://www.sigstore.dev/ https://www.sigstore.dev/

westurner 3y ago
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#generate-provenance 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.
LoganDark 3y ago
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).

sega_sai 3y ago

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 ?

Someone 3y ago

> 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.

mananaysiempre 3y ago

> 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 https://git-scm.com/docs/gitattributes#_ident

endgame 3y ago

Isn't this exactly what Nix does?