IRC channel logs
2024-09-25.log
back to list of logs
<oriansj>stikonas: thank you for making the tarball. <stikonas>formatting release notes is a bit longer but oh well <oriansj>lrvick: makefile doesn't really make sense for bootstrap-seeds (as you are supposed to be making your own if possible) <stikonas>I've also pushed new version into changelog.org file <matrix_bridge><Andrius Štikonas> and also this time we haven't made individual releases (m2-planet, mescc-tools, etc...) <matrix_bridge><Andrius Štikonas> even if we make version bumps/tags, they won't be in stage0-posix-release <stikonas>(my irc client temporarily lost connection, hence some out of order messages...) <oriansj>well, they also haven't been moving eitherftfgbvhrdjeugvuijkgrrlkcebidnrneikurhnkehlevl <oriansj>(and why I have been having a hard time finding time to make further progress) <stikonas>stage0-posix is not in a bad state right now anyway <stikonas>well, there can always be more improvements to M2-Planet / M2-Mesoplanet but oh well... <oriansj>well, I want to do the M3 work but that is a bunch of complexity to do a GAS compatible assembler and linker; along with a C compiler capable of directly building TCC/GCC and without quiet focus time, I know I can't really make progress. <stikonas>yeah, gas compatible assembler and linker would be nice <stikonas>but yes, it's hard to work if you can only spare a few minutes at a time <stikonas>it takes some time to get into the state where actual lines of code are being written <stikonas>one of the reasons why my progress with posix-runner is also very slow... <lrvick>oriansj: yeah, totally makes sense, and I buy the xxd/sed logic anyway. I'll probably just vendor the seed source (with appropriate credit) in our stage0 on the next pass, then run through building it with several different distro containers then compare with each other that they all get the same hardcoded result hash, before we pivot to using the binary in an empty filesystem with just <lrvick>that way someone can quickly conclude either every distro we used to compare the seed is compromised, or the compiled seed by all of them, that matches the hardcoded hash we expect, is in fact built from the hex0 file <lrvick>then we have our own standalone very minimal origin point for our distro that is very quick for others to reason about in-place <lrvick>then use that stage0 container to pivot to a stage1 containerfile with the complete kaem scripts generated from live-bootstrap which also can be flat and fast to review. <lrvick>and our resulting binary hashes with this simplified path should still match the ones live-bootstrap gets, which we can also hardcode <Googulator>lrvick: live-bootstrap in qemu/bare metal mode actually does build kaem-optional-seed from its hex0 source (the actual binary seed is instead builder-hex0 stage1) <matrix_bridge><Andrius Štikonas> Yeah, but we also cheat in builder-hex0 stage2 a bit, it is actually written in hex2... <Googulator>I don't really consider that an issue - the hex0 code is technically generated, but it remains fully auditable; a rogue hex2->hex0 transpiler can't insert a backdoor without it being immediately obvious in the hex0 code <matrix_bridge><Andrius Štikonas> Well, basically the only thing rogue transpiler can change is insert jumps to another function... <matrix_bridge><Andrius Štikonas> Still, one can do similar things with kernels like with POSIX apps <matrix_bridge><Andrius Štikonas> First kernel can build hex0 apps and no advanced syscalls for later stuff) <matrix_bridge><Andrius Štikonas> Then of loads kernel that can understand hex1