IRC channel logs
2026-10-23.log
back to list of logs
<roconnor>ACTION tossing computers in dumpster meme <roconnor>The current stack of software needs to be wholey abandoned. <matrix_bridge><Andrius Štikonas> There was some discussion about tar here a few years ago <matrix_bridge><Andrius Štikonas> Difference between libarchive and gnu tar was discussed <matrix_bridge><Jeremiah Orians> And it doesn’t need to be abandoned, so much as more precisely specified (as when extracted using tool abc with the following checksums, you get the correct output with files with the following checksums) <roconnor>To check that the output files have the correct checksums it might be easier if we instead built some tool to collect all the files together into one big file so we could just verifiy the checksum of that one file. <matrix_bridge><Jeremiah Orians> We already have that in mescc-tools-extras; it is called untar <matrix_bridge><Jeremiah Orians> As it’s behavior is the same for all platforms and the tar differences that more advanced tars have don’t apply <matrix_bridge><Jeremiah Orians> We simply solved it by being dumb and simple in our approach and rejecting the task of supporting anything that remotely steps outside of what we want to support <matrix_bridge><Andrius Štikonas> Bootstrappable builds have this advantage over reproducible builds: all tools are specified <matrix_bridge><Andrius Štikonas> So don't need to care that "tool variant 72" is broken <notgull>I’ve always thought tar and signals were the two inelegant parts of Unix <stabbles>Andrius Štikonas: what I tried to articulate, but maybe did not express well, is that reproducibility does not *quite* solve the trust issue as the bootstrap chain evolves over time. At any point your bootstrap chain is reproducible, but say it contains untar 1.2.3 today, and a month later you need to swap it with untar 5.3.2 as a side effect of <stabbles>adding something else in the bootstrap chain, then that can have the side effect that other tarballs are extracted differently. If your audit of source code was done post extraction, and that lead you to approve a tarball, there's a hole. If you audit the tarballs themselves, I suppose all is good. But I expect people are likely to audit sources <stabbles>I'm currently doing a scan over tens of thousands of source tarballs from nix, guix and spack (plus the handful of live-bootstrap) to try and figure out how strict and pedantic I can make a tar parser without rejecting too many package releases