Hacker News Reader

Comment by AndyKelley | Hacker News Reader

1. Yes it is cheating. That is the downside of this approach. Contributors to Zig and users of Zig don't care about such cheating, but distribution maintainers such as Debian Developers do (rightly) care. This decision is a tradeoff that favors contributors and users at the expense of system package maintainers. I am counting on a third party implementation of Zig to arise someday and solve the bootstrapping problem for system package maintainers. But in the short term, it's more important to prioritize the needs of users and contributors.

2. Whenever this happens, the contributor runs `zig build update-zig1` and commits the updated wasm kernel to the repository.

View on HN

Well you could project the wasm back to C with wasm2c, package maintainers can continue the illusion that they are bootstrapping from C.

You clearly think of package maintainers as stupid and I can assure you that we are not.

I do not think that at all. But I have witnessed tortured vivisection of codebases that were never meant to undergo that procedure, all to satisfy a fantastical taxonomy. In that regard, I am triggered, yes.

Is the argument you were alluding to that a distro wouldn't consume Zig until it can be bootstrapped by two compilers to show it hasn't been the victim of the Trusting Trust attack?

Oh sure, I won't deny that package maintenance has caused plenty of issues for upstream authors [1].

Yes that's right. More specifically they have rules about generated files. They are not allowed. Generated files such as binary blobs must be produced as part of the build process of the package.

[1]: https://www.youtube.com/watch?v=stChOsejLEQ

Distros like to compile from source, but generally don't mind bootstrapping off pre-built compilers not in the source package, since any other method means basically giving up on packaging software altogether.

The only exception that I am aware of is GNU Guix and the Bootstrappable Builds project, which aims to build a full distro starting with ~512 bytes binary, they have gotten quite far already.

https://bootstrappable.org/

Following that site, I find https://www.gnu.org/software/mes/

> GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System.

https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots...

> The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

This is important work these folks are doing. I'd love to see some distros pick it up and periodically show that they can start with some files on disk and a ten-key. USB drive and a UEFI console?

They got a lot further than GNU Mes now. The process starts with stage0, ~512 bytes of machine code. Their live-bootstrap project is another focus of work. Another thing being worked on is using the Fiwix kernel as a step towards getting Linux bootstrapped. Also higher-level languages like Ocaml are getting bootstrapped.

https://github.com/oriansj/stage0 https://github.com/fosslinux/live-bootstrap/ https://www.fiwix.org/ https://github.com/Ekdohibs/camlboot

I'm not aware of any overview/documentation of the entire process though, best check out their site and wiki and join the IRC channel.

It's only marginally less ugly than blessing one arch (like arm or x86) and running the bootstrapping with an emulator.

Don't get me wrong, I do like it more, but I realize it's mostly an aesthetic thing. Logically and functionally it's like if you just blessed a build jsing cosmopolitan libc or something like that.

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.

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)

>Can the stage1 wasm binary be reproduced by the stage2 or stage3 executable?

Yes, per (2) in 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.

But because of trusting trust, we cannot prove the security of the blob.

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!

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?

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

That's my take as well.

That's essentially how OpenJDK's bootstrapping works.

If Zig was at version 19, like OpenJDK, then Zig could just not commit stage0 and instead say "download stage0 from ... or install from your friendly distro pkg repos".

Eventually, presumably, Zig will get to that level of maturity. In the meantime, to me, it seems like not-a-big-deal to commit a very small stage0.

Reply on news.ycombinator.com