You'll wanna check out https://bootstrappable.org/ for making sure

Then again, perhaps he also infected all those fancy PCB & IC supply toolchains…

That's easy: try it with Firefox.

> Pretty sure Firefox uses Chrome as its toolchain these days.

It does not.

There is no shared code between Firefox and Chrome. They use completely different rendering engines with independent histories (Chrome uses Blink originated from WebKit originated from KHTML, Firefox uses Gecko originated from Netscape originated from Mosaic).

The only shared component is that Firefox utilizes public APIs for Google SafeBrowsing.

Disclaimer: ex-Mozillian

Oh sorry. Chrome is not a toolchain in mostly any sense. Except for its extraordinary flexibility as browsers are in general able to execute code. So I thought it was obviously a joke that one would use a browser to compiler another browser.

The "on trusting trust" attack regards using your compiler as a mechanism to infect compiled executables -- including compilers themselves, and their generated code.

I didn't mean to suggest that the two browsers shared any code.

There is actually some code sharing these days, mainly libraries. Mojo for IPC is the one I remember off the top of my head. I think also WebRTC stuff?

Yes, in the strictest sense both browsers may rely on public open source libraries, which means they have some shared code, but they do not share any code directly with each other (e.g. Chrome is not a dependency of Firefox, Firefox is not a dependency of Chrome). I see this as not equating to "code sharing" because they both happen to use a library. Ironically for other apps that'd usually be something like OpenSSL, but in the case of Firefox and Chrome they actually have entirely separate TLS codebases as well (NSS for Firefox and BoringSSL for Chrome).

For some of these shared open source libraries, either Mozilla or Google is the primary contributor/maintainer, and both organizations usually make contributions. This is true across many things, even libraries in the open source space that are not involved in the browsers themselves but may be in the toolchain (Mozilla has produced robust open source CI/CD tooling, bug trackers, etc over its history).

Similarly ANGLE is made by Google (perhaps Chrome team) and now also used by Firefox

I mean... the Firefox build has NodeJS in it now, so in a sense Chromium is in the toolchain :-)

I'm not sure why you are being downvoted, because you are technically correct - a lot of Firefox developers use VS Code, which is based on Chrome and it is part of the toolchain.

ELI5: are you really sure that when you work on Firefox source code from VS Code, that what ends up in the saved file and what gets committed to Git is what you actually see on screen?

I think I was just a bit too subtle with my joke.

VSCode doesn't seem like a "on trusting trust" attack vector since we can easily observe the git outputs of the C/C++ source and these parts often reviewed by peers. Unlike object code -- we can always take a look at the disassembly but in practice it's not scrutinized.

It's probably frustrating to those who work on Firefox to suggest that it somehow depends on Chrome. I get that. But it wasn't where I was going.

There is some kinda-out-there reality though -- with something like WASM or v8 you can theoretically run real toolchains like gcc and clang "in the browser". ;)

There are 100% VS Code workflows - you edit in VS Code, commit from VS Code, and do code reviews from VS Code and review GitHub issues from VS Code.

> frustrating to those who work on Firefox to suggest that it somehow depends on Chrome.

Maybe those developers should not look too closely at who ultimately pays their salaries :)

Clang has been compiled to WASM: https://wapm.io/syrusakbary/clang

I did check this to make sure I was still living in a sane universe, Firefox doesn't use Blink https://en.wikipedia.org/wiki/Comparison_of_browser_engines

What, no? Firefox isn't based on Chromium at all.

I think he wrote the original Go compiler.

The Go compiler used to be written in C, but transitioned to being written in Go around version 1.4 (IIRC). I believe that the Go compiler toolchain is rooted on that version (i.e., you can eventually compile the current Go compiler if you start with the compiler binary produced using Go 1.4). I don't remember the reference describing the situation in detail.

30mb hello world binary that dials 8.8.8.8 suddenly makes sense now..

And AWK, and C. And Unix.

There's no "T" in "AWK".

You're right.