COMMENTS:
Personally I wish that this can somehow be even more "better" in my opinion if this can replace containers themselves. I had once seen somebody comment that they wanted to create a gcloud course and wanted to provide a shell like environment with all gcloud tools etc., that too , cross platform but they felt docker was too heavy for such use case , so they used nix for it.
I am also wondering how cool this can be where this can be used to create things like appimage or all the other things. Since this is reproducible, we can create a such dockerfile to .deb / .pkg.tar.zst and so much more.
Damn. This is crazy idea considering you don't have to trust anybody or any code , I wish for something like zkvm combined with this where with just source code and a proof , you can verify that somebody built it and maybe even distribute it , the problem I suppose is that zkvm doesn't prove things running over the internet ( I think)
Very much on our radar, though not hard to do by hand today. Help is of course welcome on such efforts if you get cycles to spare!
First steps would be to add the actual appimage tool as a package in "user" which would be a great first package for someone. We should have all/most of the dependencies already.
fwiw, Talos now uses stagex for their builds: https://github.com/siderolabs/talos/releases/tag/v1.10.0-alp...
Unlike nix, stagex is reproduced and signed by multiple independent parties avoiding centralized trust in any single person or computer. It is also full source bootstrapped, 100% reproducible (nix is not quite there yet), container native, and toolchain agnostic (since you can use any OCI toolchain you want, docker, podman, kaniko, etc etc).
This has some tradeoffs though. Nix has more of a wikipedia-style approach to contributions where anyone can add almost anything with minimal accountability or friction. This approach positions them as more of a hobby distribution not designed for high security use cases.
On the positive side, this tradeoff means nix has a -huge- number of packages, and -most- things are reproducible, which makes it a fantastic reference for distros with more strict requirements like stagex.
Any questions welcome.
Feel free to drop by our matrix channel #stagex:matrix.org for feedback or questions any time as well!
Entirely different threat model.
The OCI spec supports multisig, multiple build engines, multiple registry engines, which are a major benefit of using standards.
You can even both build and export to OCI images with shell scripts.
You've conflated Nix and Nixpkgs. My suggestion was to use Nix as your build engine, not to base your system on the existing packages in Nixpkgs. You'd still build your own complete package set, like you're doing already. Using Nix would give you a build sandbox that is purpose-built for deterministic builds, and you won't have to work around the troubles of Docker, which is not designed for that. I'm sure you must be aware that it's effectively impossible to reproduce a Docker image bit-for-bit when building from a regular Dockerfile, and I'm sure you've had to come up with some nasty hacks to work around all that. You could also use Nix's built-in store path signing feature, which does support multiple signatures.
I do not think we gain anything using the nix format, but we would lose a lot of compatibility with the huge ecosystem of container-native build systems and infrastructure.
It's fine if it can't be installed on physical hardware (or if that isn't the intended use), but in which case, I think this point should be clarified.
To elaborate my use case, I'm interested in using minimal OCI containers as a bootable OS, so when I do an update, I can switch over to the new image (or a different image) in an atomic operation. Yes, I know there are projects like Fedora Atomic, uBlue, bootc etc, but they're all far too bloated - I want to use a minimal, musl-based, fully reproducible image-based updates.
Stagex can also easily generate immutable/deterministic live isos, full bootable server images, enclave os images, etc.
It was these sorts of use cases that made us realize no existing distro hit our threat model and caused us to build stagex in the first place.
Here are some standalone deterministic linux distros built or bootstrapped with stagex:
- https://codeberg.org/stagex/repros - Server distro designed exclusively for reproducible builds
- https://git.distrust.co/public/airgap - Minimal CLI-only workstation distribution designed for offline key/secret management
- https://git.distrust.co/public/enclaveos - Linux kernel, rust init system, and user supplied rust code for running whatever you want in nitro enclaves
- https://github.com/tkhq/quorumos - Linux/rust based enclave operating system that uses remote attestation and shamirs secret sharing to manage applications no single sysadmin can be trusted with access to.
- https://github.com/siderolabs/toolchain/blob/main/Pkgfile#L5... - Talos Linux by sidero labs just recently moved their toolchain from alpine to stagex for much higher supply chain security
Honestly stagex was built for your use case.
item_43265536