<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:05 <kaniini> i'm not sufficiently familiar with that package to make a call personally
00:27 <TemptorSent> Am I seeing things? What output do you get from 'blah=blah ; echo $blah ; echo ${blah//[a-z]/[A-Z]}'
00:34 <kaniini> raccoon:~$ blah=blah ; echo $blah ; echo ${blah//[a-z]/[A-Z]}
00:34 <kaniini> blah
00:34 <kaniini> [A-Z][A-Z][A-Z][A-Z]
00:41 <duncaen> blah; dash: 1: Bad substitution
00:45 <TemptorSent> I'mve getting "TODO"
00:46 <TemptorSent> Well, 'blah' followd by 'TODO'.. it should be an error if it's not implemented!~
00:47 <TemptorSent> BB 1.26.2 (2017-02-21)
00:49 <duncaen> same version of ash works here
00:50 <duncaen> BusyBox v1.26.2 (2017-01-21 13:49:57 UTC) built-in shell (ash)
00:58 <awilfox> I get what kaniini gets, zsh 5.2
01:00 <duncaen> that confirms that its not posix at all :D
01:03 <awilfox> jsh gives me "blah\nbad substitution"
01:03 <awilfox> bash gives me "blah\nipdb"
01:03 <duncaen> oO
01:04 <duncaen> lol bash is strange
01:04 <duncaen> it lists files in the current directory
01:05 <awilfox> duncaen: yeah, in ~ it gives me "blah\nCode getservbyport.c test"
01:05 <duncaen> but i dont get which files it lists
01:05 <awilfox> duncaen: any that are four letters
01:05 <awilfox> exactly
01:05 <awilfox> (getservbyport.c is gsbp in my ~)
01:06 <duncaen> ah interesting
01:06 <duncaen> ok bash has blah=blah; echo ${blah^^}
01:11 <awilfox> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
01:11 <awilfox> this is definitely not posix
01:11 <awilfox> j/s
01:12 <kaniini> ipdb now thats a fancy software
01:19 minimalism joined
01:25 <TemptorSent> Solution is obviously use '$(echo $var | /bin/busybox tr '[a-z]' '[A-Z]')' instead, but still, behaviour should be either corrector or thow an error.
01:28 <duncaen> s=blah; while [ "${#s}" -gt 0 ]; do c=${s%${s#[a-z]}}; s=${s#[a-z]}; printf "\\$(printf '%03o' "$(( $(printf '%d' "'$c") - 32 ))")"; done
01:28 <algitbot> [alpine-aports] main/vino: upgrade to 3.16.0 - Patchwork: http://patchwork.alpinelinux.org/patch/03/
01:28 <duncaen> :D
01:28 <TemptorSent> Okay, it looks like it's replacing each letter of blah with the pattern [A-Z], then globbing that
01:28 <duncaen> still needs two $() no idea if there is a simpler way
01:28 <TemptorSent> *lol* Yeah,
01:28 <kaniini> you people scare me
01:29 <duncaen> works in dash, posix
01:29 <TemptorSent> duncaen: I only have to do it occaionally, so it's not too horrible using tr, it's just cannonicalizing the loglevels.
01:30 <duncaen> :D wondering if there is a way to simplify and still use just posix shell
01:30 <TemptorSent> New init core is getting pretty close to done, with real error handling :)
01:31 <TemptorSent> The irritating thing about testing init is you need the entire thing working at least well enough to try to boot to be worth testing and it's a long rebuild cycle.
01:32 <duncaen> you boot it on real hardware?
01:33 <TemptorSent> duncaen: No, but it still takes a while to rebuild initfs and reboot VMs.
01:36 theMagnumOrange joined
01:36 <TemptorSent> awilfox, duncaen: Care to sanity check my stub for anything ugly before I start adding the functional modules? http://termbin.com/lqix
01:37 <theMagnumOrange> theres not a lot of packages for alpine
01:37 <theMagnumOrange> keepassx for example
01:37 <TemptorSent> theMagnumOrange: Sounds like you're volunteering to maintain them, thanks!
01:38 <TemptorSent> ;)\
01:38 <theMagnumOrange> im not expert enough. lol
01:38 <theMagnumOrange> very noob
01:38 <theMagnumOrange> all I want is pax/grsecurity on a distro
01:39 <TemptorSent> theMagnumOrange: Unfortunately, pax/grsecurity is more of a mess than it appears to be worth at this point :/
01:39 <theMagnumOrange> interesting..
01:40 <awilfox> TemptorSent: 'variable tools' (evil eval hax) and you've already lost me
01:40 <TemptorSent> theMagnumOrange: It needs some major effort to properly cleanup and have working across all archs.
01:40 <TemptorSent> awilfox: Which evil hacks?
01:40 <awilfox> list_prepend() { local var=$1 ; shift ; eval "$var=\"\$@\${$var:+ \$$var}\"" ; }
01:41 <awilfox> and friends
01:41 <awilfox> that's already beyond me
01:42 <TemptorSent> awilfox: Oh, that's probably the worst of it, basically becasue we don't have variable variables ( ${$var} or ${!var} ), we have to eval it.
01:42 <theMagnumOrange> archs?
01:42 <TemptorSent> theMagnumOrange: Architectures, sorry - apparently it's only really implmented on x86 and arm, and there are some issues there still.
01:42 <awilfox> theMagnumOrange: non-x86 computers. ARM (mobile phones, tablets, and things like the Raspberry Pi and Pine 64) is another arch. MIPS (routers, switches, and the Creator CI20) is another arch.
01:44 <TemptorSent> awilfox: so if you call 'list_prepend mylist "a b c"' it will evaluate as 'mylist="$@ ${mylist:+ $mylist}'
01:44 <TemptorSent> er, with the closing quote.
01:45 <TemptorSent> And the ${mylist:+ $mylist} is there so we only substitute in the space if mylist actually has values.
01:46 <TemptorSent> And then you get your "a b c" substitued in, so you get "a b c" or "a b c d e f" if mylist happened to already have "d e f"
01:49 <TemptorSent> awilfox: Basically, it's working around the fact that posix doesn't let you use a variablely named parameter directly.
01:50 <TemptorSent> awilfox: Okay, other than fugly posix workarounds, anything fugly :)
01:51 <duncaen> TemptorSent: i think you should use := for the options instead of =
01:51 <duncaen> : ${initfs_mnt_opts_dev_shm="nodev noexec nosuid"}
01:52 <duncaen> cho ${initfs_mnt_opts_dev_shm="nodev noexec nosuid"}; initfs_mnt_opts_dev_shm=; echo ${initfs_mnt_opts_dev_shm="nodev noexec nosuid"}
01:52 <TemptorSent> duncaen: Why? I had the intention of allowing the option to be set null at the kernel cmd line
01:52 <duncaen> to use /bin/mount defaults?
01:52 blueness joined
01:52 <TemptorSent> duncaen Yes.
01:52 <duncaen> ah ok, wanted to complain about =no :D
01:53 <TemptorSent> No, if they set it to 'no' it won't try to mount it! :)
01:53 Emperor_Earth joined
01:54 <TemptorSent> any variable that matches initfs*opt* or noinitfs*opt* will be handled as initfs*opt* with no -> =no
01:55 <TemptorSent> so using noinitfs_mnt_opts_dev_shm or initfs_mnt_opts_dev_shm=no will cause it not to mount /dev/shm.
01:56 <duncaen> why dont you use the builtin printf?
01:56 <TemptorSent> duncaen: Parsing the kernel command line to options is dead simple.
01:56 <TemptorSent> duncaen is it truly builtin?
01:56 <duncaen> printf is a shell builtin
01:56 <duncaen> type printf
01:57 <TemptorSent> which printf is giving me /usr/bin/printf
01:57 s33se_ joined
01:57 <duncaen> which is not a shell builtin :D
01:57 <TemptorSent> and type is giving me a shell builtin.
01:57 <duncaen> which only knows the PATH
01:57 <duncaen> cat is not a builtin
01:57 <TemptorSent> Okay, so I can trust type..
01:58 <duncaen> yes
02:00 <TemptorSent> duncaen: printf using builtin :)
02:00 <TemptorSent> I should have checked that before I went crazy with BB's applets :)
02:02 <TemptorSent> Okay, aside from that, anything look seriously off?
02:03 <TemptorSent> Essentially from that point, it's a matter of including whichever functions are required for our particular initfs based on the features configured.
02:03 <duncaen> i dislike the eval stuff too
02:03 <TemptorSent> duncaen: Do you have a better solution for it?
02:03 <TemptorSent> We're missing setvar
02:04 <TemptorSent> Which is POSIX IIRC
02:04 <duncaen> i test something but at the moment not
02:05 <TemptorSent> we could probably do something horible with 'set' to emulate getvar without the eval, but it would be uglier and more fragile by far.
02:06 <TemptorSent> Is it the fact that the var name isn't sanitized first?
02:06 <TemptorSent> Or just the thought of an eval?
02:06 <duncaen> everything about it :D
02:06 <duncaen> yea basically that its eval
02:06 <TemptorSent> I'll take better options if you've got 'em.
02:08 <TemptorSent> Would you prefer to substitute first, then eval? Is there a less sick way of accomplishing the same thing?
02:09 <TemptorSent> But yes, I have eval too -- I just noticed I had and extra \$
02:12 <TemptorSent> Give me posix setvar and I'll be happy. I can put up with set | grep if I need to for retrieving it.
02:12 <TemptorSent> Anyway, I'm afraid I need to head out for a few hours, but will be back on later tonight.
02:14 <duncaen> i would just keep it basic as possible i guess
02:14 <duncaen> x=${cmdline##*root[= ]}; opt_foo=${x%% *}; echo $opt_foo where i need it
02:15 <duncaen> hm need something to not get fooroot=x
02:17 <TemptorSent> duncaen: This has to support all options required by all flavors of boot, not just mounting root.
02:18 <duncaen> yea i would do this for each option one by one
02:18 <TemptorSent> duncaen: Ouch! That would require calling every single funciton possible hand having a check for it,.
02:19 <* kaniini> shops around for suitable mips64 build hardware
02:19 <TemptorSent> Currently, all I have to do is iterate through the opts and check if they have a function associated.
02:20 <TemptorSent> So I don't have to have any pre-knowledge of whatever boot process I needs wants for variable.s
02:24 <TemptorSent> On my way to go to a family dinner, thank you for taking a look duncaen.
02:25 <TemptorSent> FWIW, the existing initramfs-init uses the same eval strategy for the kernel options, but with a lot more parsing overhead.
02:26 <duncaen> hm ok
02:30 <duncaen> urgh the current one is strange too
02:31 <duncaen> this one uses a list with known variables, i would just add a long case statement instead for each variable and set it
08:58 <tmh1999> should we package libv8 in ? it is built when building nodejs. such a waste if we don't
08:58 <tmh1999> *in nodejs
09:25 atmoz joined
10:08 rrx joined
10:14 pickfire joined
10:27 rrx joined
10:34 blueness joined
11:21 atmoz joined
11:30 blueness joined
11:44 blueness joined
12:45 fekepp joined
12:48 rrx joined
13:00 StarWarsFan|afk joined
13:19 fekepp joined
13:23 rokf joined
13:49 rrx joined
14:18 <scadu> tmh1999: I think it would be a good idea
14:36 <tmh1999> scadu : I will give it a try :)
14:49 rrx joined
14:56 blueness joined
15:10 rrx joined
15:45 tmh1999 joined
16:12 dsabogal joined
16:18 tty joined
17:18 nmeum joined
19:16 czart_ joined
19:46 <TemptorSent> Query - can apk verify signatures on files other than .apks with a little manipualtion? I would like to be able to secure the payloads and authenticate them.
19:47 <TemptorSent> (In initramfs, so static apk would be even better :)
19:53 tmh1999 joined
19:58 rrx joined
20:12 przemoc joined
20:13 <TemptorSent> Will 'abuild-sign $file' give me something that apk can verify?
20:15 <TemptorSent> Also, do we have any means of encryption/decryption within APK itself hiding somewhere?
20:23 <TemptorSent> Hmm, tests are giving back 'UNTRUSTED' when signed with my own key (which is also installed in the system keys dir)
20:29 alacerda joined
20:30 <TemptorSent> Looks like it only likes '.tar.gz' format and will puke on attempting to verify any other type of file -- can this change?
20:31 theMagnumOrange left
20:45 kaniini_ joined
20:47 czart__ joined
20:49 <TemptorSent> It's not perfect, but I think I can do a mostly-trusted boot as follows:
20:51 <TemptorSent> 1. Stub initramfs (cpio) is loaded by kernel which contains /init, busybox-static, apk-staitc, and trusted keys.
20:53 <TemptorSent> 2. The rest of init is contained in signed tar.gz archives embedded within cpio archives, which can be either appended to the actual stub initramfs cpio or appended using the kernel command line (or both)
20:55 ScrumpyJack joined
20:59 <TemptorSent> 3. The stub creates the absolute minimum directory structure required to verify and extract the tarballs. The stub verifies and extracts '/init.d/files/init-main.tar.gz' and hands off control.
21:03 <skarnet> that sounds good so far, but I'm concerned that it's still a lot of infrastructure for an initramfs
21:03 <skarnet> what would the tarballs contain? methods to find the rootfs, kernel modules, that kind of thing?
21:04 <TemptorSent> 4. init-main processes the kernel command line, then verifies and extracts the appropriate tarballs (which includes the modules), sources their /init.d/init-$name files, and continues.
21:05 <skarnet> (just passing through, I won't have much time to discuss extensively tonight. I'm just saying that I find the design sound, but my minimalism nerve is tingling - it sounds overengineered for an initramfs)
21:05 <TemptorSent> skarnet: It is large for a special-purpose initramfs, but I suggest we create specific inits for certain configurations which are consistent and simple (VMs, fixed embedded, etc)
21:06 <TemptorSent> skarnet: I'm trying to solve the 'can you trust initramfs' problem.
21:06 laj joined
21:06 <skarnet> well it's like the kernel - if you can't trust it you're pretty much screwed
21:06 <TemptorSent> skarnet: The stub can be universal and installed by the trusted package manager.
21:07 <TemptorSent> skarnet: Currently, it's built locally everytime you run update-kernel, and there is no audit trail
21:07 <TemptorSent> NOTHING verifies that your installed kernel, initramfs, and modules are actually what you thought you were getting!
21:08 <TemptorSent> skarnet: This has made me reevaluate a few things regarding both the startup process and the process of building the initial environment.
21:10 <skarnet> imho the verification should be done at update-kernel time, not at boot time
21:11 <skarnet> it all depends on what you trust, but you have such a comfortable environment when the system is running
21:11 <TemptorSent> skarnet: How? What do you verify a cpio archive against if you're creating it on the fly?
21:11 <skarnet> as opposed to when booting where you have nothing
21:11 <TemptorSent> skarnet - apk.static and busybox handle everything I'm aware of.
21:12 <skarnet> published hashes on a trusted site?
21:12 <skarnet> or can you go full custom, which would of course be unverifiable?
21:12 <TemptorSent> skarnet: The only thing I'd like to have to trust is the keys we add to the archive, since we can SEE them and verify them.
21:13 <TemptorSent> skarnet: You'd be in a self-signed situation or trusting someones pubkey.
21:13 <skarnet> it doesn't shock me to have to trust alpinelinux.org's certificate
21:13 <TemptorSent> That's why I was wondering if APK knew how to do any encryption -- we could make it impossible to do anything without a boot-time parameter.
21:13 blueness joined
21:14 <TemptorSent> skarnet: Right, I mean for building a custom kernel -- you'll have to trust your own signature.
21:15 <TemptorSent> skarnet: Essentially a user-supplied key that would be required to trust anythign other than alpine (or even that, if we want to secure out kernel)
21:16 <skarnet> yes, you can bypass the verification with a "custom" option and a loud warning
21:16 <TemptorSent> skarnet: Yeah, and make it so you can explicitly trust someone else with a similar warning.
21:16 <skarnet> why not.
21:16 <skarnet> my only point is: put as much of the complexity as build time as opposed to boot time
21:17 <skarnet> and I'm now afkish
21:17 <TemptorSent> skarnet: It's not minimal, but it seems to solve the chain of trust from bootloader to os.
21:18 <TemptorSent> skarnet: How do we verify at boot time that someone didn't simply swap our known trusted initramfs-init with thier malicious payload?
21:21 <TemptorSent> skarnet: When you glance back this way, what are your thoughts on mdev during early init?
21:33 <TemptorSent> skarnet: Here's what I had as a framework before visiting the trust issue: http://termbin.com/9amn
21:35 <TemptorSent> skarnet: To ensure trust, the kernel command line parsing probably needs to be split to an early check for specific options needed for verification, and a later parsing of the whole list once we've verified the code that will be running them.
21:36 przemoc joined
21:46 <TemptorSent> Also, is there any compelling reason we need to swtich_root when using a run-from-ram configuration?
21:59 <skarnet> * mdev during early init: I'm all for it, but ncopa said there were reports of inefficiency (lots of mdev processes spawned at coldplug time) and that's one of the reasons why nlplug-findfs was written instead
22:00 <skarnet> so you'd need to check with ncopa on that one.
22:01 <skarnet> * switch_root when run-from-ram: I don't see the point if the initramfs is actually a tmpfs, and we could probably do away with it, unless there's a good reason that I missed. Check with fabled on that one, and if he doesn't have a better idea, ditch the switch_root if we run-from-ram.
22:03 <skarnet> * ensuring trust: I haven't given much thought to it, and I won't be able to tonight, so I don't want to say irrelevant shit. What's your threat model? What are you trying to protect from what? I need to have clear ideas of that in order to be able to reason on the right steps.
22:05 <skarnet> At first glance, what you're doing *looks* too complex, i.e. I feel like you're trying to protect against an attacker who would already have control of the machine anyway, and that there's no point to the complexity. But again, it's a first impression, I haven't put much thought into it, so it's quite possible that I'm wrong about it.
22:06 <skarnet> aaaand I'm gone again. TemptorSent ^
22:13 <TemptorSent> skarnet: Thanks! RE: mdev/switchroot - that's what I was guessing, so I'll talk to fabled/ncopa for details.
22:17 <TemptorSent> skarnet: RE - Threat models: 1. Attacker who can maliciously alter contents of initramfs through altering files used by or during update-kernel. Once build, there is no way of verifying integrity of initramfs or modloop.
22:19 <TemptorSent> skarnet: There are many, many vectors available which can not be verified if we include everything found by lddtree in the initramfs.
22:19 <TemptorSent> skarnet: My goal would be to make the initramfs featues essentilly static and signable so they can be verified like any other package.
22:21 <TemptorSent> Other than verifying the signature on an entire image including all contained files, I'm not aware of a means of verifying the integrity of the initramfs. The even better move would be to bake the stub into the kernel and sign the kernel.
22:22 <TemptorSent> ...but that would require infrastructure changes beyond the stuff I'm messing with now.
22:22 <TemptorSent> Have a good time!
22:24 <TemptorSent> (I'm thinking I should just break down and write the stubloader in C at this point, but I need to knock some rust off my sysctl-foo)
22:42 <TemptorSent> Okay, this is strange ... 'find / -xdev | grep /dev' gives me the entire contents of dev... same goes for /sys, etc.. Anyone else?
22:44 <TemptorSent> Hmm, does find see UNDER mountpoints somehow?
22:46 <TemptorSent> ...no, it looks identical. Is it just my find that's broken, or is this a bug biting anyone else?
22:56 <skarnet> bb find or findutils find? I wouldn't swear that the former does the right thing with -xdev, it may be cutting corners.
22:58 <skarnet> "The even better move would be to bake the stub into the kernel and sign the kernel." -> I agree with that. I don't think it's reasonable to attempt to secure something that can be built on a compromised machine.
22:58 <skarnet> The point of a distro is to provide working packages and that's one of them.
22:58 <TemptorSent> bb find
22:59 <skarnet> look at the code, it's usually pretty readable. Look at how -xdev works. I wouldn't be surprised if it didn't stop at pseudofs boundaries when run from a pseudofs itself. oslt.
23:00 <TemptorSent> Which is dangerous, because I was about to trust it with a find / -xdev -delete !
23:00 <skarnet> good thing you checked first then. :P
23:00 <skarnet> generally speaking you shouldn't need to do that.
23:00 <TemptorSent> skarnet: Yeah, that's a nasty bug..
23:00 <TemptorSent> skarnet: Do you see the same behavior?
23:01 <skarnet> I'm not testing atm.
23:01 <TemptorSent> skarnet: Or is it related somehow to my fubar kernel/mods situation?
23:01 <TemptorSent> (I really should reboot at some point)
23:08 <TemptorSent> Yup, it appears they're being naieve when deciding if it's a device or not:
23:09 <TemptorSent> if (G.xdev_dev[i] == statbuf-st_dev) goto found;
23:10 <TemptorSent> er '->st_dev'
23:10 <skarnet> yeah
23:10 <skarnet> so it won't detect a tmpfs inside a tmpfs
23:10 <TemptorSent> skarnet - or a bind mount, etc.
23:10 <skarnet> you could ignore it, or send a patch that also detects st_ino
23:10 <skarnet> checks st_ino*
23:11 <skarnet> um, wait, no, that's not going to help
23:11 <TemptorSent> skarnet: Would that solve the corner cases?
23:11 <skarnet> no
23:11 <skarnet> the right thing, I'm afraid, is to scan /proc/mounts at start
23:11 <TemptorSent> Yeah, no -- we need to check the mount table, and their mount table is whats broken
23:11 <skarnet> yeah
23:12 <TemptorSent> They break /proc/mounts on my machine -- wrong resource written perhaps?
23:12 <skarnet> I suggest ignoring for now
23:12 <skarnet> don't shave the yak, just find a way to do what you want to do without needing find -xdev
23:12 <TemptorSent> bind mounts are not showing up properly in /proc/mounts for me.
23:13 <TemptorSent> skarnet: Yeah, what I'm trying to do is wipe out the entire FS except the mounts :)
23:13 <skarnet> that's rewriting switch_root
23:13 <skarnet> and if it's initramfs, you should know exactly what's there
23:14 <TemptorSent> skarnet: Nah, I just want to clean it out so I can extract in a known environment.
23:14 <skarnet> if you can't explicitly list the contents of your initramfs, you're in trouble
23:14 <TemptorSent> The problem is the kernel append command.
23:14 <skarnet> extract in a subdir
23:15 <TemptorSent> We could have an unknown initramfs appended .
23:15 <skarnet> what
23:15 <skarnet> you can only have one initramfs
23:15 <TemptorSent> Nope, you can append as many as you want!
23:16 <skarnet> how would that even work? what /init is run?
23:16 <TemptorSent> With cpio... Append is litterally that.
23:17 <skarnet> do they overlay upon one another? and if a file conflicts, let God sort it out?
23:17 <TemptorSent> skarnet: the first init written to the initramfs is run, since the rest don't overwrite.
23:17 <TemptorSent> look at the cpio semantics
23:17 <skarnet> well if you want to do something secure, I'd say, declare that unsupported. You don't overlay over Alpine's initramfs, period
23:18 <TemptorSent> skarnet: Actually, it's more secure if we DO use multiple overlays, since each can be signed and packaged.
23:19 <TemptorSent> skarnet: Then as long as the stub loader can verify the tarballs match the sigs, we know we're only working with trusted files.
23:19 <skarnet> there are certainly simpler ways of doing that. Again, complexity in the initramfs is something I'm *very* wary of.
23:19 <skarnet> I like your stub + tarball archive idea better.
23:19 <TemptorSent> skarnet: Thats why we'd like to have a clean-slate to extract the tarballs -- a tmpfs mounted at /.init.d handles what we need and the rest goes to hell
23:20 <skarnet> you don't need an inside tmpfs, you just need a subdirectory.
23:20 <TemptorSent> skarnet: That's the probelm we can't get tarballs into the initfs without wrapping them using cpio and appending them.
23:21 <TemptorSent> skarnet: I think the tmpfs would be cleaner since we can actually destroy it when we're done with it even if we're on a run-from-ram root.
23:21 <skarnet> rm -rf is hard
23:21 <TemptorSent> skarnet: And the idea was to avoid the irritating issue by using xdev :)
23:22 <TemptorSent> IOW, the simple solution is what I was trying to use until I hit the buggy implementation.
23:22 <skarnet> find -xdev is only good to prune a trunk without touching a branch. That's not what you want to do here.
23:23 <skarnet> anyway, bbl again
23:23 <TemptorSent> Alright, thanks -- I'll keep poking at it.
23:28 <TemptorSent> skarnet: Realistically, mounting /run right from the start (before bootchart/splash/etc) and using that may make the most sense.
23:29 minimalism joined
23:30 <skarnet> big fat no on that one
23:31 <skarnet> that would break the /sbin/init contract
23:31 <skarnet> you want some additional fs in the initramfs, you mount them, you do your stuff, *and you unmount them*
23:32 <TemptorSent> skarnet: Hmm, the documents for switch_root define that it handles moving /dev /proc /sys /run
23:33 <skarnet> that's a mistake
23:33 <skarnet> you should never need to do that
23:34 <TemptorSent> skarnet: I agreed, it should not be generally necessary, but in this case it's explicitly defined behaviour.
23:34 <TemptorSent> skarnet: And is required to support some of the use-cases that have been identified as important.
23:35 <skarnet> let me break it down very clearly
23:35 <skarnet> You. Do. Not. Need. To. Mount. A. Tmpfs. Inside. A. Tmpfs.
23:35 <skarnet> Ever.
23:35 <TemptorSent> skarnet: Um, how do you switch to a real-root then?
23:36 <TemptorSent> You can't split off one directory of your tmpfs and mount -o move it somewhere else last I checked.
23:36 <skarnet> By not switching if your real-root is a tmpfs, I guess. :P
23:37 <TemptorSent> Right, I'm looking at the non-run-from-ram configurations here.
23:37 <skarnet> anyway, I've spent way more time discussing this tonight than I originally planned to
23:37 <skarnet> I kinda need to get on with my life.
23:37 <TemptorSent> for run-from-ram I plan to just drop into the system and maybe do a remount with fstabs opts if needed.
23:38 <TemptorSent> skarnet: Sorry, I don't mean to distract you from your time away from the computer.
23:38 <skarnet> of course, that's why you keep highlighting me
23:39 <TemptorSent> skarnet: I figgured it'd end up in your backlog :)
23:40 <TemptorSent> I think I'll just parse mounts and go from there.
23:45 <TemptorSent> Screw it, for now we'll go with just worrying about initial keys -- we can figure out how to do the rest properly later... It might be easier just to use chroot early and switch_root at the end.