This was acknowledged with 20cb26c. The original intent, to offer a bootstrapped build process for serai-runtime, is now actively known to be unfulfilled. As we originally wanted such a process, we still still do now, and should track this.
Unfortunately, this is quite approximate to being bootstrapped and anything closer would likely be infeasible for the scope of Serai. Specifically, it'd involve composing live-bootstrap (or adopting derivative works, such as the presentation seen within StageX) and defining the packages necessary to get to a functional Rust compiler. While these packages are already defined as a subset of the StageX tree, the packages within the StageX tree have not actually been generally validated to be free of binaries and there's a track record to the contrary. The most 'practical' route would be to fork StageX and introduce the entire infrastructure and CI in order to be assert no binaries other than hex0 are actually used or exported throughout the entire build process.
Given this is sufficiently close to bootstrapped to achieve the stated goal, and there's a mountain of other evidence regarding the integrity of the runtime (being reproduced from Windows, macOS, Linux with glibc, and within containers, Linux with glibc and Linux with musl), this thankfully can be considered as exceedingly low on our priority list.
This was acknowledged with 20cb26c. The original intent, to offer a bootstrapped build process for
serai-runtime, is now actively known to be unfulfilled. As we originally wanted such a process, we still still do now, and should track this.Unfortunately, this is quite approximate to being bootstrapped and anything closer would likely be infeasible for the scope of Serai. Specifically, it'd involve composing live-bootstrap (or adopting derivative works, such as the presentation seen within StageX) and defining the packages necessary to get to a functional Rust compiler. While these packages are already defined as a subset of the StageX tree, the packages within the StageX tree have not actually been generally validated to be free of binaries and there's a track record to the contrary. The most 'practical' route would be to fork StageX and introduce the entire infrastructure and CI in order to be assert no binaries other than
hex0are actually used or exported throughout the entire build process.Given this is sufficiently close to bootstrapped to achieve the stated goal, and there's a mountain of other evidence regarding the integrity of the runtime (being reproduced from Windows, macOS, Linux with
glibc, and within containers, Linux withglibcand Linux withmusl), this thankfully can be considered as exceedingly low on our priority list.