2 ms·
Yeah seems like a nightmare since so much of the auto-magic that nix does to fix binaries (shebang rewriting and ELF .so patching) does so by injecting absolute
by JamesSwift 3y ago
Yeah seems like a nightmare since so much of the auto-magic that nix does to fix binaries (shebang rewriting and ELF .so patching) does so by injecting absolute paths (to /nix/store). So all of those would need to be reshimmed for your entire system
EDIT: theres also work being done to move to content-addressed nix store, in which case changing these things would invalidate the content hash
- tgamblin 3y agoIn Spack we rewrite strings in binaries, strings in text files (including shebangs), and RPATH/RUNPATH values. It's not hard to find store prefixes in binaries -- they have hashes in them so they're easy to identify. It's hard to lengthen them -- things in text files and in ELF fields can be made longer, but to make strings longer you need to find all references to them, which is impractical. So we build with long paths. Relocating is really only a matter of relocating prefixes. I am not sure how it would affect a content-addressed nix store, but I'm also not 100% sure why you want a content-addressed nix store. Addressing by the derivation hash (which is also what Spack does) lets you find valid build substitutes... would you index that separately for a content-addressed store? Is the goal to allow multiple versions of non-reproducible builds in the same store?
- JamesSwift 3y agoI'm not 100% sure, but I know one benefit of content-addressed derivations is that they are secure by default. i.e. if the hash matches the build is trusted vs the traditional need to have separate "trusted signatures" and signing workflow to whitelist particular builders.
- Nullabillity 3y agoHow do you reliably modify length-prefixed strings? Terminated strings? Delimited strings? Partial strings? Checksummed strings?