<xentrac>it's unusual to want to run atexit things in both children <oriansj>stikonas: the reason for _exit instead of exit has to do with behavior for file handles for the forking process. If you build kaem with gcc and replace the _exit with an exit, you'll see infinite looping as it tries to continue reading the script but from the absolute beginning of the script file as the handle was reset by the exit call <oriansj>_exit doesn't deal with any cleanup and just does a syscall terminiate immediately. <oriansj>So it is a C behavior thing we are working around. <oriansj>That being said, I have merged your change as it is a reasonable approximation of the functionality you want but there may be bugs in it we just simply haven't found yet. <oriansj>and I am curious if anyone is looking into the untar security vulnerabilty or if I need to get into it. <oriansj>also it appears the fuzzer never checked that case and thank you for finding that bug, Fixing it now <oriansj>Benefit of having a community, someone around here knows something you don't yet and we all benefit from those differences in experience <oriansj>possibly, I've been mostly concerned with input crashing rather than providing a useful error message <stikonas>also added that forgotten after hook (with the new exec call) <oriansj>ok and now M2-Planet will handle all argument inputs correctly (except for -D foo and using int bar=foo; because I haven't figured out a correct solution for how to give it a better debug message but it does give an error message and no segfault) <Hagfish>if those end up getting stored in a distributed append-only log (rather than a private microsoft-owned database) then linking (hopefully reproducible) binaries to source code to maintainers should suddenly become the standard for Free software projects <Hagfish>package managers could come with lenses to say "this new version you are downloading has been vouched for by a new developer, do you want to trust them?" <Hagfish>i'm not sure, actually, what sort of trust model you'd use for making useful decisions around that <Hagfish>a developer must have had their work checked for 3 years before they can vouch for other people's code? <Hagfish>that would make buying and selling developer credentials potentially a viable market, and there might need to be laws around that <Hagfish>i suspect that we're quite close to reaching a point where developers will need to own a hardware key to sign their commits if they want their code to be trusted by anyone <stikonas>most of the free software is not coming from github though <stikonas>or at leats most widely installed software <stikonas>most of the big players self-host rather than use github (Linux, GNU, Freedesktop, Gnome, KDE...) <Hagfish>i guess i mean the long-tail of small projects (quantity not quality) <Hagfish>although i hope that distros are encouraged to do something similar (as Arch seems to be already) <Hagfish>i'd like to think that distros already have some precedent for thinking about the problem of "do i trust this developer" <Hagfish>separating the package maintenance from the release process does mitigate the problem somewhat <Hagfish>and having a separate testing repo from production/LTS packages <Hagfish>obviously that didn't stop clever/subtle issues like debian's week SSL package <Hagfish>i think there was also a case where a disgruntled upstream developer put an "if (debian)" branch in the code, which managed to get packaged <Hagfish>(because obviously the packager isn't reviewing every line of code, and they may not even have tried running the package before it got to the mirrors) <clemens3>just run the numbers, 100 million lines of code minimum, by thousands of developers.. how many lines of code and number of developers are black hats.. <Hagfish>it would almost be easier to run the numbers backwards and say "how many attacks have their been?", but i guess the worrying answer is "we don't know" <clemens3>well, attack runs on honest bugs and "accidental" bugs.. <clemens3>so how many bugs are there, how many bugs get created anew.... time a factor of which are exploitable, times how long it takes to find them and exploit them.. <Hagfish>yeah, if we assume that every security critical bug was actually maliciously added, then basically all software is pwned all the time <clemens3>well, bugs for sure are not all black hat back doors, but each normal bug still is an attack vector.. and honests are a lot, not <clemens3>plus the bugs on purposes, plus real backdoors which are hidden.. <clemens3>guess how many lines of code your systems has.. firefox 36, kernel, 20 million, plus a couple other big projects <oriansj>all operating systems are a game of trust <clemens3>basically you can not trust it 100.0 %, that is a given <oriansj>Assuming one could audit 1KLoC a day, to audit 100MLoC would require 1000 people working for 100days straight <oriansj>So if we as a society wanted a good universal audit for all software, it becomes a rather affordable problem to solve <oriansj>as we need only make a trusted core that is audited <oriansj>clemens3: It only takes 5 people to change the world for everyone else <clemens3>while doing it, we could rather start from scratch and build decent software while at it.. <clemens3>wayland looks not that much better than what it tries to replace <oriansj>clemens3: what do you think bootstrappable is? 5 years ago it was an impossible dream. Now it is a reaslity <clemens3>but meanwhile people are creating a monster like rustc <clemens3>i couldnt so far reproduce that one even having gcc <oriansj>guix package definitions along with the ability to snapshot code at a point in time make the problem solvable <clemens3>one guy is working on mrustc while a hundred others pollute the whole stack more <oriansj>clemens3: yet progress was made and it can still be used to make a bootstrap chain. <clemens3>you catch up and by that time firefox consist of a couple hundred million lines <oriansj>that is why one needs a community to solve big problems <clemens3>but the community is a free for all plus commercial interests <clemens3>in my eye rust/firfox is not open source, just in theory <oriansj>everyone has off days, life events and reasons to stop and take a break but once a community has 5 people, suddenly progress continues while you take time for you. <clemens3>reproducable builds admittably took on some steam <clemens3>i hope the bootstrappable becomes a movement as well <oriansj>clemens3: it already is, look at how many people are here <clemens3>like nobody cares a project if you can not only build it, but only build it from some base gcc or even assembler tuff <clemens3>but at the same time you need more hardware, binaries, firmware to get stuff build <clemens3>different trends in different directions <oriansj>do amazing stuff and the world will change, even if it takes longer than you hoped. <clemens3>can of course always ditch firefox and rust.. i am close to it <oriansj>The barrier to progress will only lower day after day as we make the problem more solved. <oriansj>clemens3: netsurf and dillo have tiny engines <clemens3>yeah, some day need to install m02orwhat and give some feedback.. meanwhile I try my teeth on mrust.. <oriansj>Saying something can't be solved never moves the conversation forward. Grabbing a hammer or text editor in anger will force it to move in the direction you want. <clemens3>yeah, both nice, but not sure how many bugs and regarding security, as dillo is official without https and last update was like 7 years or so <oriansj>If something really matters to you. DO SOMETHING to make the world better. <oriansj>a single man with a shovel can remove a mountain in a couple decades of work <clemens3>i am compiling mrust right now, as you said, small steps <oriansj>it might take 22years with a shovel but every problem can be broken with enough anger, love and focus <oriansj>help with testing, improve documentation, correct spelling mistakes, help spread the word, There are thousands of little things that really add up. <stikonas>had some issues with it (mostly on non amd64 platforms) but other than that it's usable <clemens3>it is a great project, just rustc is not <stikonas>yeah, it's a bit annoying that rustc has almos no backward compatibility... <stikonas>although, it sounds that they might be doing better job than ocaml <clemens3>i have 8+gb mem, and it is using that plus another 8gb of swap.. <stikonas>at leats rustc n can be built with rustc n-1 <oriansj>a guix package bootstrap chain is better than no bootstrap chain, regardless of how ugly it is. <stikonas>clemens3: yes, it uses a lot of memory, but rather than letting it use swap, consider zram <clemens3>of course, preaching to the wrong ones here.. <stikonas>I was ablt to go past that high memory stage even on 4 GB arm64 machine (although, hit some other bug later) <clemens3>anyway firefox is a project that has been taken over <clemens3>and is actively or passively being sabotaged.. really need some other browser.. <clemens3>falkon is very nice, but didn't have a release for two years, so not how about security (updates).. <stikonas>clemens3: probably fine regarding security updates, it's just a small GUI on top of qtwebengine <stikonas>as long as your qt is up to date, it should be fine <clemens3>i like it a lot actually, just for some ebanking and others i still rely on firefox.. <clemens3>no time yet trying to compile ungoogled chromium, gave mrustc another try first.. <stikonas[m]>I find ungoogled-chromium takes more compilation time on average than Firefox <stikonas[m]>Each version takes maybe 16h to compile on my machine <stikonas[m]>Firefox is more initially (mrustc/rustc) but then much quicker <clemens3>yeah.. google/alphabet doesn't care much if others can compile it.. <clemens3>and i bet your machine isn't the slowest <clemens3>i need 16 hours to compile kernel, tools, X, qtweb and falkon and epiphany on 7 threads and 8 gb mem <stikonas[m]>my machine is somewhat oldish laptop (maybe 5 years old) <stikonas[m]>The whole GCC bootstrap is much faster than any modern software <clemens3>just downloaded the git mes and mescc-tools.. <clemens3>building the last one, am i missing something? <clemens3>clemens@quad!1220 2021-10-05 20:19:19 ~/quad/src/lfs/tmp/mescc-tools-1.3:-)make <clemens3>fatal: No names found, cannot describe anything. <clemens3>make: *** No rule to make target 'M2libc/bootstrappable.c', needed by 'M1'. Stop. <stikonas>well, mescc-tools uses git submodules, I think mes repo doesn't <clemens3>ok, might be something for the README/INSTALL ***dongcarl7 is now known as dongcarl
<stikonas>clemens3: it's probably mentioned in stage0-posix repo... <clemens3>in case.. can also provide the build.log or .log file if needed.. <stikonas>hmm, I was usually building mes with M2-Planet, so can't really tell what's going on <stikonas>clemens3: which mes repository are you using? main one? <stikonas>clemens3: that looks wrong in your configure step: checking for guile [2.0]... 3.0.7 <stikonas>but guile and gcc are not required for building mes... <clemens3>i guess mes and stuff have been created, just some docu stuff at the end maybe <stikonas>well, something went wrong with configure guile detection... <stikonas>fossy: I think we have a small problem with checksums <stikonas>Downloading: deblob-4.9: Exception: Checksum mismatch <stikonas>I guess upstream likes to silently update the script <stikonas>we probably need to include those in the repo <stikonas>oriansj: we also need to think how to fix live-bootstrap after ARCH/bin split <stikonas>having $ARCH/bin rather than bin-$ARCH helped a tiny bit, but later stages still break <stikonas>so mescc-tools-full part works, but mescc-tools-extra doesn't <stikonas>maybe we have to try to undo how that directory restructuring that live-bootstrap does in rootfs.py script