erictapen has joined #nixos-security
pie_ has joined #nixos-security
erictape1 has joined #nixos-security
erictapen has quit [Ping timeout: 272 seconds]
pie_ has quit [Ping timeout: 258 seconds]
erictape1 has quit [Ping timeout: 244 seconds]
lassulus_ has joined #nixos-security
lassulus has quit [Ping timeout: 246 seconds]
lassulus_ is now known as lassulus
pie_ has joined #nixos-security
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 268 seconds]
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 246 seconds]
Foxboron has joined #nixos-security
erictapen has joined #nixos-security
<gchristensen> andi-: but why bother writing a bootloader entry if you can't boot it? (w.r.t. integrating the signing with the writer)
<andi-> well you can access the key in the activation script if the path (not a nix Path type) was given..
<Foxboron> gchristensen: Do the nixos have a email for the security team? or just induvidual emails?
<Foxboron> the nixos security team*
<gchristensen> andi-: I haven't integrated it, but my latest boot was secure-booted with a signed systemd-boot, kernel, and initrd
<gchristensen> Foxboron: just individual emails -- the expectation is you'll encrypt to each, which is simpler than having many people share a decryption key
<Foxboron> gchristensen: It's nothing sensitive really. I know some teams use gpg exploders
<Foxboron> But thats noted. Thanks :)
<gchristensen> aye
<gchristensen> you don't strictly *have* to use encryption of course
<Foxboron> Indeed
<gchristensen> andi-: exactly :) (path to the key)
<gchristensen> andi-: can't activate w/out being root anyway
<andi-> yeah
<andi-> But some tighter integration would be nice... not requiring additional commands. And all packages should be in nixpkgs.. I have at least one that is still required for my workflow that I haven't submitted
<gchristensen> I had to package efitools for key generation
<gchristensen> otherwise just binutils and sbsigntool
<andi-> yeah, I think thats it
<andi-> regarding security: I am spending the day trying to compile Nix on OpenBSD... So far packaging for OpenBSD isnt' that different/difficult
<gchristensen> nice!
<pie_> andi-, we compiled it for freebsd at the end of december \o/
rain1 has quit [Ping timeout: 240 seconds]
<pie_> andi-, mic92 may or may not be working on getting nixpkgs bootstrapping with freebsd again
<andi-> I just want to give it a shot to see how well it works.. Not sure if it will go anywhere :D
<pie_> andi-, ping em if you get anywhere? :P
<pie_> *me
<pie_> I am Interested In Using The Fruits Of This Labor
<andi-> Maybe I can at least get the dependencies and nix itself added to the ports repo. Should be feasible
<pie_> andi-, nix itself seems relatively portable
<pie_> (>)
<pie_> * (?)
<pie_> i dont know what kind of super fancy features nixpkgs uses though
<andi-> yeah, it is just that the aws thingy makes some false assumptions and I had to patch a few memset_s locations..
<pie_> well idk about nix either, isnt there lik extensive use of fnacy systemd stuff?
<pie_> *like
<pie_> aws thingy?
<pie_> fnacy = fancy
rain1 has joined #nixos-security
<andi-> the aws-cpp-sdk
<pie_> does nix have like some kind of aws stuff hardcoded in?
<pie_> why?
<pie_> we had some fun with this >_>
<{^_^}> nix#2604 (by 0mp, 2 weeks ago, open): contains Bash-specific syntax
<pie_> turns out autoconf doesnt actually le you change the shell afaict and it should in facto only contain sh syntax
<pie_> hm actually ill go poke the guy if he can update the thread with the workaround we had for that...
erictapen has quit [Ping timeout: 246 seconds]
<andi-> the configure script doesn't yet un completly since I am still packaging things while baking pizza :) So far it seems to work without any bashisms
<gchristensen> andi-: my nixos-rebuild boot does the thing automatically now
<andi-> gchristensen: nice
<gchristensen> is really the extent of the hacky version of my change
<gchristensen> samueldr: ^
<andi-> oh, systemd-boot.. Not using that :D
<andi-> still doesn't support booting with FDE (inlcuding /boot) :/
<gchristensen> yeah
<gchristensen> so it does leak some info
<andi-> In general I prefer just signing Grub and the having everything else hidden. Can also avoid a few signatures that way.. NOt really significant I guess. The one thing grub doesn't do yet is disable the very limited resuce shell once the password was entered wrong. I have a WIP patch for that somewhere.. ETOOMANYPROJECTS..
erictapen has joined #nixos-security
<gchristensen> I hear that
<gchristensen> I am, most likely, not going to finish this, and just turn off secure-boot.
<andi-> Current employment will probably come to an halt in ~2-4 Months since stupidity so I might have another 3 Months of paid time to work on my TODOs.. not so bad afterall
<gchristensen> ack
<gchristensen> Im not sure what creates /boot/EFI/BOOT/BOOTX64.EFI and thus I'm not automatically signing it
<Foxboron> gchristensen: packages by systemd-boot
<Foxboron> you'll see it copied when running bootctl update
<Foxboron> packaged*
<gchristensen> hrm, I think I'd want to replace that, then
<Foxboron> Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
<Foxboron> essentially
<Foxboron> Personally been writing scripts to keep track of efi binaries and signing keys, along with making sure the objcopy bundles are created. It's a bit crude but works
<andi-> pie_: now hitting the exact same bashism :/
<andi-> The big unknown in my journey is how to sandbox the builders..
<andi-> there is only chroot for our use case
<pie_> andi-, did you solve the bash problem
<pie_> just got back from shopping, checking if my dudes been on
<pie_> actually i did not even notice theres a pull request on that thread
<pie_> or did that just happen
<pie_> andi-, so yeah i guess, do you have this yet?
<{^_^}> nix#2607 (by 0mp, 1 week ago, merged): Remove some bashisms from
<pie_> andi-, yeah i guess thats what i was thinking of re: no fancy systemd user isolation somethingorother, or is that a kernel feature
<pie_> so lots and lots of chroots? :P
<pie_> can those serve equivalent functionality?
<andi-> pie_: there is `proot` which is used to build ports in chroots, it supports various isolation levels if you want to call them like that.
<andi-> pie_: I saw the PR. I should actually have a version that has the fix but I have to check in detail.. Pizza is done now :)
<pie_> andi-, pfff
<pie_> andi-, why is there no information for why it was reverted
<pie_> eelco pls
<andi-> I am checking issues right now.. Haven't found a hint :/
<pie_> ok after some digging, andi-
<{^_^}> nix#2618 (by 0mp, 3 days ago, merged): Escape square brackets in
<pie_> prs on top of prs
<andi-> thank you both also just found it -,-
<pie_> it was referenced at the end of the first pr
<pie_> :I
<andi-> So using bash now.. Seems like xmldoc is missing and never checked by configure
MichaelRaskin has quit [Quit: gchristensen last call: if nobody is in the process of writing a good post about medium-term RFC SC selection rules, I will write a quick-hack «please state your opinions» one]