3 ms·

Perhaps the distro devs could maintain their own golden WASM blobs that they compiled themselves and thus trust. Could be the same process as SecureBoot / packa

Perhaps the distro devs could maintain their own golden WASM blobs that they compiled themselves and thus trust. Could be the same process as SecureBoot / package signing keys.

edwintorok 4y ago
Can the stage1 wasm binary be reproduced by the stage2 or stage3 executable? Aside from a "trusting trust" type of attack that seems fine, and every modern distro relies on some bootstrap binary for C compilers anyway (usually older versions of them), so it wouldn't be that much different of a bootstrapping problem than bootstrapping GCC itself. (See the GNU Mes project which attempts to bootstrap from just a very small hex interpreter)
- Arnavion 4y ago
  >Can the stage1 wasm binary be reproduced by the stage2 or stage3 executable? Yes, per (2) in https://news.ycombinator.com/item?id=33915480 https://news.ycombinator.com/item?id=33915480 >and every modern distro relies on some bootstrap binary for C compilers anyway (usually older versions of them), so it wouldn't be that much different of a bootstrapping problem than bootstrapping GCC itself. Yes, that's exactly my point. The zig-wasm-bootstrap package could just be a Build-Depends of the zig package.
  - melony 4y ago
    But because of trusting trust, we cannot prove the security of the blob.
AndyKelley 4y ago
This is a brilliant idea which I hadn't thought of before. If the Debian folks are happy with this approach, this could save us a lot of trouble!
- cryptonector 4y ago
  It's what OpenJDK does. OpenJDK releases very quickly nowadays, and requires version N or N-1 to build version N. If that works for OpenJDK, presumably it should work for Zig. Does it really prevent the Ken Thompson attack though? Well, it means the attacker has to be a committer to keep the attack from eventually breaking, or that the attack will eventually break. You could use a different compiler written by someone else to increase the amount of work and coordination needed by the attacker to pull it off, but this is not reasonable to require for new (or new-ish) programming languages -- it'd more likely squelch programming language research and development than aid it. There are multiple Java implementations, but does Debian build the OpenJDK with non-OpenJDK implementations? Would that eliminate the trusting trust problem?
  - Quekid5 4y ago
    > Does it really prevent the Ken Thompson attack though? Well, it means the attacker has to be a committer to keep the attack from eventually breaking, or that the attack will eventually break. If the attack is sufficiently well squirreled away in code that rarely changes then that "eventually" could be a very long way away. However, I imagine the risks of Trusting Trust are a tad overblown considering how much other lower-hanging fruit there usually is to attack through. For example just sneaking in subtly broken commits containing security vulnerabilities.
    - cryptonector 4y ago
      That's my take as well.
cryptonector 4y ago
That's essentially how OpenJDK's bootstrapping works.

Perhaps the distro devs could maintain their own golden WASM blobs that they compiled themselves and thus trust. Could be the same process as SecureBoot / package signing keys.

edwintorok 4y ago

Can the stage1 wasm binary be reproduced by the stage2 or stage3 executable? Aside from a "trusting trust" type of attack that seems fine, and every modern distro relies on some bootstrap binary for C compilers anyway (usually older versions of them), so it wouldn't be that much different of a bootstrapping problem than bootstrapping GCC itself. (See the GNU Mes project which attempts to bootstrap from just a very small hex interpreter)

Arnavion 4y ago
>Can the stage1 wasm binary be reproduced by the stage2 or stage3 executable? Yes, per (2) in https://news.ycombinator.com/item?id=33915480 https://news.ycombinator.com/item?id=33915480 >and every modern distro relies on some bootstrap binary for C compilers anyway (usually older versions of them), so it wouldn't be that much different of a bootstrapping problem than bootstrapping GCC itself. Yes, that's exactly my point. The zig-wasm-bootstrap package could just be a Build-Depends of the zig package.
- melony 4y ago
  But because of trusting trust, we cannot prove the security of the blob.

AndyKelley 4y ago

This is a brilliant idea which I hadn't thought of before. If the Debian folks are happy with this approach, this could save us a lot of trouble!

cryptonector 4y ago
It's what OpenJDK does. OpenJDK releases very quickly nowadays, and requires version N or N-1 to build version N. If that works for OpenJDK, presumably it should work for Zig. Does it really prevent the Ken Thompson attack though? Well, it means the attacker has to be a committer to keep the attack from eventually breaking, or that the attack will eventually break. You could use a different compiler written by someone else to increase the amount of work and coordination needed by the attacker to pull it off, but this is not reasonable to require for new (or new-ish) programming languages -- it'd more likely squelch programming language research and development than aid it. There are multiple Java implementations, but does Debian build the OpenJDK with non-OpenJDK implementations? Would that eliminate the trusting trust problem?
- Quekid5 4y ago
  > Does it really prevent the Ken Thompson attack though? Well, it means the attacker has to be a committer to keep the attack from eventually breaking, or that the attack will eventually break. If the attack is sufficiently well squirreled away in code that rarely changes then that "eventually" could be a very long way away. However, I imagine the risks of Trusting Trust are a tad overblown considering how much other lower-hanging fruit there usually is to attack through. For example just sneaking in subtly broken commits containing security vulnerabilities.
  - cryptonector 4y ago
    That's my take as well.

cryptonector 4y ago

That's essentially how OpenJDK's bootstrapping works.