IRC channel logs
2021-06-29.log
back to list of logs
<Hagfish>"Reproducible builds help counter subverted builds. After that, we can focus on attacks like the trusting trust attack." <stikonas>fossy: I briefly checked guile dependencies, it looks like we'll have to stay with older dependencies for now (I still need to find versions that work) <Hagfish>depending on what he means by "focus on", it sounds like he's saying that people shouldn't start tackling "trusting trust" until all software everywhere is reproducible <stikonas>trying to build newest versions of dependencies, quickly gets us into the dependency hell <stikonas>guile->pkg-config->glib->meson->python (and then even more) <stikonas>I'll try older pkg-config that is written in shell <civodul>Hagfish: it's odd because to a large extent we're "after that", IMO <stikonas>well, my reading of that email is basically that you shouldn't be discouraged that trusting trust can still be done in the firmware level and still work on higher levels <Hagfish>stikonas: that's a very charitable interpretation, thank you <Hagfish>i agree with civodul, that for most purposes we can consider that reproducibility has been "solved", it just needs some people to keep maintaining it <stikonas>and POSIX bootstrapping is also mostly solved <stikonas>well, bootstrapping gcc from source given POSIX environment <Hagfish>right, yeah, from minimal POSIX to maximal POSIX :) <Hagfish>what would you say is the biggest outstanding piece of work for (software) bootstrapping? <stikonas>well, there is maintining bootstrapping on newer arches (e.g. riscv) and also bootstrapping kernel <Hagfish>i saw someone on HN yesterday complain that tcc doesn't support mipsel, which was interesting <Hagfish>yeah, good point about the kernel layer <stikonas>I think it only supports x86, x86_64, arm,arm64 and maybe riscv in latest git <Hagfish>someone responded that debian have a fork which supports mipsel <stikonas>are there a lot of machines (not counting routers) that support mipsel? <stikonas>there was that longstone laptop that rms used... <Hagfish>i think it was in the context of a toy OS that was targeting an emulated mipsel environment <stikonas>yeah, pkgconfig will be a bit annoying... We'll have to go through a few versions... <stikonas>0.3.5 from 2003 is the newest we can start with, because newer ones need glib (which needs pkg-config) <Hagfish>that's an interesting metric, actually: how many copies of itself does a given piece of software need in order to compile it from nothing <Hagfish>for some pieces of software, that number will be zero <Hagfish>for others it might be in the double-digits <Hagfish>it could be called the Stikonas Bootstrappability Score, or SBS for short :) <stikonas>it's not very well defined, it depends on whether you are willing to do some patching (especially build systems, etc...) <stikonas>and I think old glibc does not like musl... <stikonas>strange, guix must have solved this issue... <stikonas>oh, there is --with-internal-glib to use vendored glib in pkg-config that doesn't then have circular dependency <oriansj>civodul, Hagfish: my interpretation of David A. Wheeler's email was: the hyper majority of all software isn't even remotely reproducible so much more work is still required before we could consider it done. DDC only works on reproducible build environments after all. So even if we had the bootstrap done, those things couldn't be trusted because we could do DDC on them to establish that trust even with a trusted source and trusted build <oriansj>So the logical course of action is to help get more software reproducible now, as the bootstrapping group is kicking ass and will be ready when they are ready. <oriansj>The Microcode problem is the one after bootstrapping is solved not before. <oriansj>I do however love the idea of software having a: Stikonas Bootstrappability Score <stikonas>Hagfish: it's fine. Not any worse than vendored gnulib <oriansj>Those that could be built by Mes and below get a zero and each additional bootstrap dependency is again point against having a good score. <Hagfish>interesting, yeah, i like that idea too <stikonas>So hopefully something like this would work pkgconfig-0.29.2->libffi-3.3->libatomic_ops-7.6.10->gc-8.0.4->guile-psyntax-bootstrapping/guile-3.0.7 (hopefully, right now this step fails with compile error) <oriansj>with software you can't build from source having <oriansj>if they want a lower score provide the source code under a FSF approved license and after we are able to build it, you'll get a lower score. <stikonas>looks like guile 3.0.7 compile errors are due to using C11 features... <stikonas>well, no chance of --std=c11in gcc 4.0.4 <fossy>stikonas: these compile errors, which c11 feature exactly is being used? <stikonas>fossy: but maybe the simplest would be to build gcc 4.7.4 using the same hacky approach as gcc 4.0.4 <oriansj>well we will not need the c++ framework unless guile needs it (shouldn't) <oriansj>So in theory one could do GCC C compiler only until we have guile bootstrapped. <stikonas>alternatively, somebody needs to patch guile <stikonas>but we'll probably need to build gcc 4.7.4 anyway <stikonas>gcc 4.0.4 will be too old to go to modern gcc <oriansj>well scheme interpreters don't pick up C features for no reason. Generally they are picked up for measurable performance improvements. <oriansj>for example the performance difference between if/elseif/else vs switch/case in scheme can be up to factor of 10. <oriansj>if/else if/else is trivial to implement in the cc_* C subset, switch is more complex (and I haven't done it yet because it hasn't been a priority need yet.) <fossy>stikonas[m]: if you just remove the fixup commit #127 can be merged