Post
@khinsen It is another way to build “full-source bootstrap” similar to what @janneke et al. did in #Guix and what @stikonas et al. did with live-bootstrap.
Technically, it reuses stage0, M2-Planet, Mes/MesCC, and kaem as developed by these fine people:
https://stagex.tools/packages/bootstrap/stage0/
I suspect the dependency graph is close if not identical to that of live-bootstrap (the one of Guix has more Scheme in it 😄 among other things).
@khinsen Other than that, I sympathize with the sentiment of @soupglasses: it seems to be a corporate-backed project, solving the security problems of companies in a spirit quite different from that of the #bootstrapping work that enables it.
It is good that companies understand the value of this work, but disappointing that they’re (again) freeriding on volunteer work and sweeping its empowerment message under the carpet.
@khinsen Docker is not a packaging platform, so the entire project suffers greatly from that. There is also no attempt i can find to build a "container-native build platform", only running downloads and build commands directly with ADD and RUN keywords.
There is a lot of hacks like appending `--network=none` to commands, and a lot of the build stage is informal. There also seems to be absolutely zero tests being run at all on any of the packages to check for correctness. The most i found is Go downloading the official package binaries after its build, and doing a sha512sum compare to them?
How they have made a functional tool-chain up to Ruby without seemingly any automated tests is mind mindbogglingly crazy. I have packaged one or two things with bootstrapping/reproducibility in my life, and i can say that for most projects this is still an edge case that will bring a lot of bugs and assumptions in their system that you likely will not have. Its a really hard task, with correctness being difficult to guarantee.
On another note, a lot of this work here seems to be reusing bootstrapping/reproducibility work, without adding anything new that I can see. This is not really a problem, but the licesnse used rings alarm bells.
This work is licensed as ISC, when the bootstrapping world is well known for licensing the works as GPLv3, even the build steps themselves with projects like Guix.
Each stage of their bootstrap is reusing some GPLv3 licensed work, in full or in large parts. This can be done in ISC licensed code, but how its done would likely break the GPL.
One example i found is the bootstrapping binary `hex0-seed` that they show prominently on their website. This is a GPLv3 licensed work directly from stage0, and it stands there without attribution or acknowledgement of being GPLv3.
I would personally avoid this project, it seems to be a project that takes a lot of GPLv3 work around bootstrapping as their main work, and licensing it ISC with a brazen ignorance to proper licensing etiquette around GPLv3, which is a recipe for disaster.
@soupglasses Thanks, that's the kind of reply I was hoping for!
I suppose one could build a reproducible-builds platform on top of OCI, but as you say it takes a specifically designed build platform.
The licensing issues are surprising, I'd expect anyone in this field to be aware of the importance of respecting licenses!
A space for Bonfire maintainers and contributors to communicate