IRC channel logs

<oriansj>I really should write up the .login_env standard and try to get it into login shells.

<oriansj>nikolar: http://paste.debian.net/1328768/

<nikolar>well, good luck, i guess

<oriansj>yeah, I fully expect to fail to convince anyone to change.

<nikolar>i am pretty sure that's what ~/.profile is for

<nimaje>that's what pam_env or login.conf is for

<nimaje>well, pam_env dropped per user configs for some strange reason

<oriansj>nikolar: as I understand it, bash looks for .bash_profile then .bash_login then .profile; so if .bash_profile or .bash_login exists; it'll never look in .profile unless one explicitly include a source command.

<nikolar>eh fair enough

<nikolar>you should use .profile instead of .bash_profile probably

<oriansj>nimaje: login.conf doesn't appear to be per user but system wide.

<oriansj>nimaje: looking at pam_env; looks like I need only convince distros to do: session optional pam_env.so user_envfile=.login_env and then get shells to look for an environemnt variable for overriding the default configuration locations.

<oriansj>and it appears that per user settings for pam_env are disabled by default for most distros: https://superuser.com/questions/130135/why-doesnt-my-environment-variable-get-set due to a CVE in its behavior: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708

<oriansj>which I am guessing has to do with PAM changing its own behavior after reading the user ~/.pam_environment file which sounds like a serious design issue.

<oriansj>as it would only make sense to read user variables after a successful login and then creating the variables to pass to the user's login shell. (Which could also just read the file and get the same)

<pabs3>from #ada <Shark8> ih8u2, The problem is over-reliance on AdaCore, IMO. Which is why I'm working on a bootstrap compiler on Java, and a self-hosted compiler.

<pabs3>full discussion https://paste.debian.net/hidden/474e8bb5/

<nimaje>oriansj: the per user file is ~/.login_conf

<nimaje>hm, not sure what the problem with changing ~/.pam_environment to a symlink to some other file is, that it reads that file with more priveleges too, so the user could point it to some file they can't read, so that pam_env does the reading for them?

<kerravon>oriansj - i guess i'm talking about the scenario where you don't trust the firmware

<kerravon>putting the source - and even executables - onto CF via normal means isn't an issue so long as you don't actually execute any of that code without verifying it first

<kerravon>and if the required executables are already sitting on the CF, then you only need to construct software to read the CF and display the bytes prior to executing those bytes

<kerravon>I'm using the Book 8088 as an example of something that actually traditionally has a BIOS and is presumably a simpler design that makes it difficult for there to be some booby trap in it

<kerravon>but using an 8088 processor in particular instead of say a 68000 seems odd if you have a choice

<kerravon>but i don't know of a Book 68000

<kerravon>actually, i just remembered - you can construct a CPU purely out of ROM chips

<kerravon>but i guess anything you buy new - e.g. even the CF card - with modern technology you could put a booby trap into it

<kerravon>and that goes for the EEPROM too

<kerravon>and is the 68000 chip you're using really ancient?

<kerravon>and what is the point of any of this when someone can just walk into your house and threaten you with a gun?

<kerravon>it's unclear what the objective is

<kerravon>i think perhaps a better objective is not absolute trust that there are no booby traps, but basically absolute trust that you know how to derive modern computing from base code

<kerravon>perhaps - if you were transported to a terraformed Mars, with no data, but you do have an IBM mainframe and plenty of blank punched cards, and you can take a book with you - how many punched cards do you need to hand-punch before you can switch to keyboard input?

<kerravon>and then at what stage can you switch to a higher level language - noting that you can switch to Sector C in 512 bytes

<kerravon>and we could refine that process until you have a C90 C compiler

<kerravon>and perhaps whichever team gets to the compiler first gets to rule Mars

<kerravon>so there is incentive to minimize the keyboard input at every step

<kerravon>and perhaps finding the optimal interim version(s) of C

<oriansj>kerravon: it is fine not to trust the firmware; we always can make our own (unfortunately such work is always going to be platform specific)

<oriansj>EEPROMs could be tested in a manner which would make backdoors harder to implment and easier to detect.

<oriansj>as for the amount of code required to go from punched cards to keyboard, it is honestly quite minimal. SET can be done in less than 1KB (probably under 300B if someone was clever about it)

<oriansj>toss in the bios routines for reading a keyboard and setting chars on a screen and you'll be done

<oriansj>then it is quick to type in hex2 and M0 => cc_* => M2-Planet+mescc-tools+mescc-tools-extra => world

<oriansj>but yeah the wrench problem in security is generally covered by only one honest bootstrap is required.

<oriansj>and the more alien, weird and distinct bootstrap roots; the harder it becomes for anything to stay hidden.

<Googulator14>oriansj: do we have a POSIX version of SET?

<matrix_bridge><Andrius Štikonas> https://github.com/oriansj/stage0/blob/master/stage1/High_level_prototypes/SET.c

<oriansj>Googulator14: yeah, SET is a very simple text editor which anyone would be able to hack together in a couple hours (even in assembly or hex0)

IRC channel logs

2024-09-08.log