<oriansj>sam_: would I be reasonable to guess that in post_src_prepare it is referencing a global variable S which is used by emerge to indicate the build directory? <stikonas>well, install procedure is probably quiccker to test... <stikonas>oriansj: there is a wiki page with ebuild variables, let me find it for you <oriansj>and I am guessing there is a place in my setup procedure setting up the overlay is probably optimal <oriansj>(atleast in terms of testing purposes) <stikonas>well, any overlay stuff is not necessary for basic install <oriansj>(forgive the slow progress, as I am testing everything and building with only a single core in qemu is slow) <oriansj>stikonas: fair, probably a good idea to put it after the essential luks/grub setup and reboot bit <stikonas>but as soon as you try to build e.g. rust stuff (including librsvg) you either have to increase your binary seed (so use rustc-bin) or bootstrap it <oriansj>well right now the current build target is going to be: xinit slim i3-wm dmenu x11-xserver-utils grub2 cryptsetup linux screen bash most binutils cgdb curl fdupes gcc gdb git gpg guile-2.2 htop make ncdu ranger stow tig time tmux trash-cli tree as that would be at feature parity of Debian's default GUI setup <oriansj>but yeah if I include mpv and sway, I would definitely need to deal with rust <oriansj>(vim/emacs too, can't believe I forgot to mention those >.<) <stikonas>so I basically masked -bin packages on my install (/etc/portage/package.mask/binary has */*-bin) <stikonas>oh emacs depending on USE flags can easily pull in rust <stikonas>if you build gtk gui, I imagine it would bring librsvg <stikonas>emacs with USE="svg" even has direct dependency on librsvg and hence rust <oriansj>so emacs gtk install after we setup the overlay and emacs no-x prior <oriansj>so it would effectively cover setting up USE flags and updating USE flags <stikonas>yes, but updating USE flags is not tricky, even automatically <stikonas>there are different ways 1. temporary one-off override via env varaible (USE="-something" or USE="something). 2. per package setting in package.use. 3. global make.conf (which might be tricker to edit automatically but I think euse from app-portage/gentoolkit can do it <oriansj>stikonas: figuring out which USE flags to use and what they mean however seems like something that requires understanding of how to find that information <stikonas>yes, there are lots of them and I'm afraid there is not easy way but reading description of all of them. And even then it might not be clear <stikonas>if I do manual install, I install ufed (curses interface for setting global USE flags, and it shows list of all USE flags and their descriptions <stikonas>(euse --info seems to show similar info but without ncurses interface, it just prints all descriptions) <oriansj>well euse isn't in the stage3 install, so probably need to write up a step for installing it and a bit about how to use it <sam_>you can definitely avoid Rust, it just may take a bit of work <oriansj>sam_: oh, I am not completely avoiding rust. Just until after the core setup is done and everything else can be done as a user with sudo <stikonas>yeah, rust stuff if best left for post-install... <stikonas>if you just want to document core install, then leave it out <oriansj>heck, the gui bit is going to be done as a user if possible <oriansj>only kernel, grub, cryptsetup and sudo (and the new admin user setup) really need to be done as root (the nano replacement bit is optional) <oriansj>stikonas: well I am going to do a full install procedure to feature parity with debian/arch/guix <oriansj>so selecting the overlay is going to be a step with notes explaining what it does and the consequences of if they don't do it. Prior to doing any user builds <oriansj>sam_: your little function made grub buildable in 1GB ^_^ <sam_>there are some little hacks you can do to make things use more I/O but less RAM too <sam_>drop -pipe from *FLAGS, and use -Wl,--no-keep-memory in *FLAGS <oriansj>good to keep in my back pocket if I end up having to hit that situation <oriansj>well I just mistook euses for euse from app-portage/gentoolkit <oriansj> although app-portage/euses seems easier to use for looking up USE definitions <oriansj>hmmm emerge is still not liking my cryptsetup USE flags <oriansj>(full file contents are sys-fs/cryptsetup gcrypt static !udev ) <sam_>show me the output in full? <oriansj>it is in a qemu vm so I don't have copy paste, so lets see if I can use curl to post it somewhere <oriansj>ooh app-text/pastebinit might be helpful here <oriansj>sam_: that is the output from emerge -av sys-fs/cryptsetup &> foo <sam_>wgetpaste is another nice one <sam_>you have both gcrypt and openssl on <sam_>also, static requires -gcrypt <oriansj>ok mine now is: sys-fs/cryptsetup gcrypt static -gcrypt !udev !openssl <oriansj>but I have static and !udev so that doesn't make sense to me <oriansj>or am I supposed to do something like sys-fs/cryptsetup static gcrypt -gcrypt ? <oriansj>and I wrote a package.use file but somehow a different use is being picked up <oriansj>ok, so I deleted my /etc/portage/package.use/cryptsetup file and that seems to have resolved the issue <oriansj>I though was supposed to override the default package USE definition <oriansj>so does the /etc/portage/package.use/* just concat with the default package definitions? <oriansj>because I honestly thought the /etc/portage/package.use/* USE statements would have been used and it made me feel very dumb for not being able to figure out why the emerge was failing <oriansj>but progress is being made forward and something new has been learned <oriansj>and is there a way to lookup the default USE definitions for a package prior to an emerge failing? <sam_>equery u, emerge -pvO, I think there's some others <oriansj>well I got grub to prompt for password and boot linux. now to figure out how to get systemd to prompt the user for the password to unlock / <aggi>don't forget, cryptsetup/luks my kick a small system into OOM condition <aggi>luksFormat --pbkdf-memory <aggi>not sure if there was other options to consider <aggi>i had encountered problems with default cryptsetup options 1GiB RAM available... <aggi>and i could say some more about this type of "security", off-topic in here <oriansj>aggi: I maanaged to build that with 1GB of ram by reducing to only 1 build job <oriansj>I think I need sleep to figure this out <aggi>oriansj: i was referring to something else, cryptsetup requires alot of RAM while unlocking the volume key <aggi>on low-RAM systems it may be impossible to unlock the volume ***silver.libera.chat sets mode: +o ChanServ
***silver.libera.chat sets mode: +ooo ChanServ oriansj janneke
***silver.libera.chat sets mode: +o oriansj
***silver.libera.chat sets mode: +o janneke
***lukedashjr is now known as luke-jr
***genr8eofl_ is now known as genr8eofl
<stikonas[m]>High RAM usage is a deliberate feature of some hash functions, makes it harder to bruteforce in parallel <aggi>stikonas[m]: and it is, a useless feature <aggi>because brute-force resistance can be achieved at minimal costs <aggi>with passwords involved, thats a sufficiently strong password + seed, and any fast 256bit hash <aggi>i am still convinced, a non-primitive LFSR-matrix is the most efficient and resistent with both hashing, and any ECB-cipher mode to prevent known-plaintext key recovery <aggi>however, i prefer big block-sizes with ECB-ciphers, such as 512byte (4096bit); another reason why i reject dm-crypt/cryptsetup <aggi>with AES, cipher block size is 128bit, uhum...; thats why i don't care about various block-modes, because with the ECB implementation variant of mine a non-primitive recurse LFSR-matrix prevents all known-plaintext key recovery <aggi>i don't at least bother with any elaborate password-hashing, because the pw-input is blown up to a _single_ 4096bit ECB block-key <aggi>i don't know precisely, my cipher design fits into 8KiB RAM or something at that scale... <aggi>minor mistake, the ECB block key alters itself depending on what's encrypted with it <aggi>anyway, tcc-toolchain with bounds-checker enabled failed with various configure scripts; i'll keep it disabled for now <mihi>aggi, memory-hard key derivation functions are a question of convenience: would you rather make your passphrase 4 characters longer, or have your key derivation function take a gigabyte of RAM? Assuming that your passphrase (even with that four additional letters) still contains less entropy than the derived key has bits, your bruteforce resistance is about equal. (And people easily overestimate <mihi>the entropy of their own chosen passphrases). <mihi>But for all KDF I know, memory can be configured, so if you don't like your memory being used, you can avoid it and choose a longer passphrase instead. <oriansj>all engineering is tradeoffs. There is never just one answer to all questions save of course for 42 <doras>fossy, stikonas: I'm working on adding a modern binutils to live-bootstrap. I managed to build 2.38 (2.39 will probably work as well) right after GCC 4.7.4. I have one question though: are there any binaries/libraries/headers we want to intentionally avoid when building it? <doras>I wasn't registered on IRC so my message may not have been visible to IRC users. I'll send it again. <doras>fossy, stikonas: I'm working on adding a modern binutils to live-bootstrap. I managed to build 2.38 (2.39 will probably work as well) right after GCC 4.7.4. I have one question though: are there any binaries/libraries/headers we want to intentionally avoid when building it? <doras>I mean, do we want to exclude anything in particular from the final package, or should I just take e.g. Fedora as reference for which files to include in the package? <Hagfish>(wow, it's really cool that live-bootstrap is at a stage where adding modern stuff to it isn't too much work) <Hagfish>(using something like Fedora as a reference seems to make sense, but you're right to ask the question. thanks for your work on this) <oriansj>Hagfish: well yes, the idea is: do the really hard work first and use better and better languages and tools as they become available. <oriansj>the less hard work is where bikesheds tend to show up and I am cool with any and all shed colors one chooses as long as someone else does the painting. <oriansj>Much like the question of what is the best C library or the best window manager or best package manager or the best kernel to use. I am happy to use any and all provided I am able to continue to make progress forward. <oriansj>heck, after gentoo I'll probably write a procedure for a *BSD (or two) <Hagfish>"as long as someone else does the painting" i love that. freedom (with the correct incentive structure) really is the solution to a lot of problems <doras>I ended up taking a bit of Fedora and a bit of Arch. It should hopefully cover everything we'll need. <unmatched-paren>oriansj: What if some monster wants to paint the shed an obnoxious shade of vomit green? :) <doras>I'm recalculating the hashes to see they remain reproducible. <stikonas[m]>Though you might need to wait till another weekend for my review <oriansj>unmatched-paren: then the monster can enjoy their shed and we can use it (or not based on personal choice) until someone takes the effort to make a better shed. <oriansj>for example if someone decided to bootstrap GCC in brainfuck; then neat we have another bootstrap path for GCC (not that I could trust it but it would exist) <oriansj>If someone bootstrapped Hanna Montana Linux, take the wins they gave us and continue to move forward. <oriansj>Who does decides, so if you don't like the direction the monster is heading; pick up your text editor or IDE and start pushing in the direction you want to see progress. Learn from the monster's good ideas and avoid the bad ideas. It cuts both ways, you can use anything you want; which means other people can choose not to use your work in their work if they so desire. But by sharing what we learn, we can bridge the gaps and all become <oriansj>better as we go along our bootstrapping adventure. <oriansj>for example I made a FORTH interpreter, thus far it hasn't been used for anything. (same could be said for many things I have made) <oriansj>although in interesting news, i guess I need to tweak that function as it recognizes The Linux kernel being built as c++ <sam_>wonder if we should add .C too to catch e.g. gcc <sam_>oriansj: if desired, you could do something like [[ ${CATEGORY}/${PN} != sys-kernel/gentoo-kernel ]] && return <oriansj>sam_: maybe setting if we did a count on the number of cpp files and set a threshold <oriansj>say having 20 cpp files is the point at which we label something a c++ program sort of thing <sam_>yeah, should be easy to change the if (( to do that actually <sam_>(you can use Bash in full in bashrc, and also ebuilds, fwiw) <oriansj>I am thinking of adding echo "${CATEGORY}/${PN}: ${count}" >> ~/matches so that we could after the fact have data to look at to make decisions on