You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was exploring Azure Linux from a bootstrappability standpoint, specifically, building it on top of live-bootstrap without additional external binary dependencies. (Conflict-of-interest disclaimer: I'm one of live-bootstrap's developers.)
The way Azure Linux is built comes very close to achieving this, using a Linux From Scratch-based strategy for creating the initial "raw" toolchain - very similar to what was done to bootstrap Gentoo previously. Unfortunately, this is all defeated by the use of a prebuilt Azure Linux Docker image to wrap the LFS environment, creating precisely the kind of circular dependency (and potential Trusting Trust attack vector) that bootstrapping from source is meant to avoid.
As far as I explored, beyond this initial step, all further steps rely only on binaries built in the previous steps, without pulling in further precompiled binaries. Therefore, having a NO_TOOLCHAIN_CONTAINER=y option to disable containerization of the raw toolchain build would enable propagating trust from a bootstrapping environment to the Azure Linux toolchain, and eventually the whole distribution.
The text was updated successfully, but these errors were encountered:
Thought about this more, and now I would like to propose a 3rd mode as well: build raw toolchain outside any container, use it to build packaged toolchain #1, build another raw toolchain in container, use that to build packaged toolchain #2, and compare the 2 sets of packages. This would further build trust via Diverse Double Compilation - assuming that toolchain packages are reproducible, of course.
Thank you for reaching out. I think that supporting a bootstrap scenario without requiring the docker container would be a very useful feature.
You are correct to point out that after using the docker container to compile the temporary tools, everything else in our toolchain is compiled from source, with no additional binary seeds. We essentially mimic the LFS process in the container, and then copy that toolchain out to be used in a chroot. We then use the chroot (which contains GCC and RPM build tooling) to build all our toolchain SPEC files.
From what I can tell, the live-bootstrap project currently only builds a 32-bit X86 toolchain. Can you confirm this? The project appears to contain at least partial support for both x86-64 and ARM64, but the python tool mentions only x86 support.
Azure Linux currently only supports 64-bit x86-64 and ARM64 architectures. I don’t think we would be able to start from live-bootstrap unless we also built a cross-toolchain to compile our 64bit packages.
I was exploring Azure Linux from a bootstrappability standpoint, specifically, building it on top of live-bootstrap without additional external binary dependencies. (Conflict-of-interest disclaimer: I'm one of live-bootstrap's developers.)
The way Azure Linux is built comes very close to achieving this, using a Linux From Scratch-based strategy for creating the initial "raw" toolchain - very similar to what was done to bootstrap Gentoo previously. Unfortunately, this is all defeated by the use of a prebuilt Azure Linux Docker image to wrap the LFS environment, creating precisely the kind of circular dependency (and potential Trusting Trust attack vector) that bootstrapping from source is meant to avoid.
As far as I explored, beyond this initial step, all further steps rely only on binaries built in the previous steps, without pulling in further precompiled binaries. Therefore, having a NO_TOOLCHAIN_CONTAINER=y option to disable containerization of the raw toolchain build would enable propagating trust from a bootstrapping environment to the Azure Linux toolchain, and eventually the whole distribution.
The text was updated successfully, but these errors were encountered: