<samueldr>
gchristensen: I migrated to mruby to get out of non-bash busybox-ash!
* samueldr
is exhausted
<gchristensen>
:)
<samueldr>
trying to move out of trello
<samueldr>
(still)
<samueldr>
nothing as a single tool comes close to it, as in an unopinonated thing to throw notes, media, links into something that is spacially organized and organizable
<samueldr>
at least that I found
<samueldr>
though I've made my peace with moving my different workflows from it to different tools, but still not sure how and what
<samueldr>
I used it *so much*, I didn't realized how much
<gchristensen>
(it might be okay to keep using it :x)
<samueldr>
the way atlassian has been "reminding" me to get an atlassian account, but without telling why, not sure
<samueldr>
or how they'll "helpfully" destroy the team permissions model, so now everyone is an admin
<samueldr>
I don't know anything that atlassian has been involved with that hasn't been pain
<samueldr>
I sure won't mind if I'm wrong with trello, but I don't want to wait until it's too late
<gchristensen>
+1
<samueldr>
I also prefer being in control of my things, so that's an occasion
<gchristensen>
yea
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-chat
<edef>
samueldr: so i onboarded everyone onto Atlassian Cloud
<edef>
samueldr: like, everyone with a corp email
<edef>
samueldr: and… i haven't been able to figure out how to give the one person with a Trello account access to it
<aleph->
Heh
<aleph->
gchristensen: So out of curiosity how broken were the openstack modules?
<aleph->
Just from a sec perspective?
<aleph->
Actually... wonder if I can just deploy openstack via docker...
<aleph->
Seems I can. This should be interesting...
<colemickens>
hm, can gpg be made to always prompt when it receives requests over the extra socket (meant for forwarding)?
<aleph->
I think so...
<aleph->
I know I accidentally set mine to do that
<aleph->
Apparently openstack via docker is fairly well supported
<evelyn>
i set the yubikey to always need a button press before an operation because I couldn't reliabbly maek gpg prompt when doing something
<emily>
you could write an awful hack to shim in between that buffers writes to the socket and waits for approval before forwarding
<emily>
you could then reuse that hack for ssh-agent forwarding :P
ajs124 has quit [Quit: killed]
das_j has quit [Quit: killed]
ajs124 has joined #nixos-chat
das_j has joined #nixos-chat
slack1256 has joined #nixos-chat
pie_[bnc] has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
AluisioASG has quit [Quit: No Ping reply in 180 seconds.]
AluisioASG has joined #nixos-chat
jasongrossman has joined #nixos-chat
<jasongrossman>
I have a question that's only indirectly related to NixOS. I know almost nothing about Windows, and I have a friend who would like to try NixOS but is currently running Windows ...
slack1256 has quit [Ping timeout: 260 seconds]
<jasongrossman>
Can someone please tell me whether, if my friend deletes her Windows installation in order to install NixOS, there's a way for her to install a fresh copy of Windows later (without having to buy installation media)? And if not, is it easy to back up an installation of Windows and reinstall from the backup?
<jasongrossman>
Thank you!
<samueldr>
it depends on the windows version, but assuming windows 10, the media is freely downloadble from microsoft
<samueldr>
I'm not sure about the details of the implementation, but I seem to recall that even for computers that didn't ship with a key in-firmware, windows 10 should be able to know it got upgraded and re-intsall
<jasongrossman>
Oh, great. Thank you! That's a win for NixOS then
AluisioASG has quit [Read error: Connection reset by peer]
<samueldr>
but that's something you probably want to research
AluisioASG has joined #nixos-chat
<jasongrossman>
Yes. Great. Thank you!
<jasongrossman>
sameuldr++
<jasongrossman>
Ugh
<jasongrossman>
samueldr++
<{^_^}>
samueldr's karma got increased to 220
<elvishjerricco>
Heheh my kexec hack and my pci passthrough monstrosity apparently work together perfectly. I can passwordlessly reboot into my windows vm that passes my only gpu through, and also passwordlessly reboot back to my NixOS system.
<samueldr>
switching VMs?
drakonis has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
<elvishjerricco>
samueldr: Nope. My NixOS system is natively installed to the system. Then I have a `nesting.clone` system that disables all the GUI stuff and simply boots a qemu vm of Windows with PCI passthrough of the GPU. This way the linux side of the system acts as normal while Windows is running.
<samueldr>
"as normal" but without a GPU :)
<samueldr>
nice, though
<elvishjerricco>
Then I have a stupid system for booting with LUKS encrypted /boot
<samueldr>
what's the GPU?
<elvishjerricco>
nvidia ti 1050. Forget the exact details
<samueldr>
good enough :)
<drakonis>
a nice gpu
<elvishjerricco>
Here's the silliest part
<elvishjerricco>
I haven't used the windows VM for anything practical yet :P
<elvishjerricco>
I've spent 50x more time making it work than actually making use of it
<elvishjerricco>
Planned on using it for Steam games
<elvishjerricco>
but Steam came up with Proton like immediately after I made it
endformationage has quit [Quit: WeeChat 2.6]
<elvishjerricco>
Anyway the kexec hack is to reboot LUKS systems without a password by storing the password in initrd for the reboot kernel to read from. Somewhat simple, very silly, and surprisingly useful
<ashkitten>
tfw you find a bug so ridiculously simple in a thing that you can't comprehend how this hasn't been caught by now
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-chat
<drakonis>
elvishjerricco: haha steam crew
drakonis has quit [Quit: WeeChat 2.8]
cole-h has quit [Ping timeout: 260 seconds]
hax404 has quit [Ping timeout: 272 seconds]
hax404 has joined #nixos-chat
<ashkitten>
hmm thinking of checking out btrfs
<eyJhb>
ashkitten: I should as well. But ... Time
<ashkitten>
thing is, i'm fairly happy with zfs right now
<ashkitten>
idk right now
<ashkitten>
is btrfs reliable and well supported?
<ashkitten>
i know red hat dropped it at some point
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
* sphalerite
is waiting for bcachefs to be super awesome and production-ready and will then maybe switch from zfs
<viric>
I use btrfs everywhere for many years already
<viric>
so far I lost less files with it than with ext4 or xfs.
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
* etu
is following the same tactic as sphalerite
<MichaelRaskin>
I just mix BtrFS use and Ext4 use. It has been a long time since BtrFS had problems.
<viric>
MichaelRaskin: when you are at their irc channel it's a bit scary for the bugs they are aware of in some kernels :)
<MichaelRaskin>
They only need to be 10 times more reliable than consumer data storage devices for this not to really matter in the backup tradeoffs
parsley936 has joined #nixos-chat
* eyJhb
Only using EXT4...
<srk>
is there a paste supporting ansii codes? :D
* srk
is about to fallback to asciinema
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
<manveru>
srk: btw, opencl seems to work with mandelbulber, but only if you install it in your systemPackages (to make sure it uses same nixpkgs version as the system)
<srk>
cool, good to know!
<srk>
manveru: during a morning walk I have had this 'oh noes another project moment' when I've remembered generating random fractals discussion :D
<srk>
I think I'll try to use genetic algo to mutate em similar to afl_fuzz :D
<manveru>
lol
__monty__ has joined #nixos-chat
hax404 has quit [Remote host closed the connection]
hax404 has joined #nixos-chat
* hyperfekt
is using bcachefs in production and recommends people wait a bit longer beore switching to it
<hyperfekt>
wherein production is my laptop lol
<__monty__>
I wonder how ZFS/Btrfs would differ if they were mainly designed for SSDs.
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
obadz has quit [Quit: WeeChat 2.8]
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
jasongrossman has quit [Ping timeout: 240 seconds]
obadz has joined #nixos-chat
srk has quit [Changing host]
srk has joined #nixos-chat
hax404 has quit [Ping timeout: 240 seconds]
hax404 has joined #nixos-chat
ajs124 has quit [Ping timeout: 260 seconds]
das_j has quit [Ping timeout: 260 seconds]
aszlig has quit [Ping timeout: 260 seconds]
aszlig has joined #nixos-chat
das_j has joined #nixos-chat
ajs124 has joined #nixos-chat
<aanderse>
anyone here not using channels for nixos, just a git checkout?
<srk>
yes
* srk
does
<aanderse>
i've never done that
<aanderse>
any tips on a good workflow for that?
<aanderse>
i'm interested in doing it
<adisbladis>
aanderse: I have nixpkgs as a submodule of my configuration
<srk>
I'm using checkout in /etc/nixpkgs for system and another copy for work in home
<srk>
with two entries in nix.nixPath (nixpkgs and nixos-config)
<aanderse>
NinjaTrappeur: awesome, thanks for sharing :D
<NinjaTrappeur>
__monty__: I can cherry pick some commits not yet in the channels
<aanderse>
__monty__: i assume binary cache
<NinjaTrappeur>
and yes, I want to sync with the channels to leverage the binary cache :)
<aanderse>
__monty__: ohh, misread your statement, ignore me
<NinjaTrappeur>
aanderse: you're welcome :)
<__monty__>
Do overlays on top of a channel give you the same flexibility?
<adisbladis>
__monty__: Well, yes. But also no. :)
<adisbladis>
Hm, actually no.
<adisbladis>
overlays can only override packages, not module definitions
<adisbladis>
And you couldn't just cherry-pick a patch from master
<__monty__>
You can import modules though.
<__monty__>
And you can't literally no, but you can overlay everything that is affected for your case, right?
<adisbladis>
Yeah, and suddenly you have this rube goldberg machine to avoid subtrees ;)
<adisbladis>
__monty__: What I've done before in private repos is to wrap nixpkgs in a derivation and apply patches
<__monty__>
Imo it's not that complicated. It's what I naturally adopted. Overlays are easy enough and importing a module's not that bad.
<adisbladis>
That's kind-of nice, but it can be hard sometimes if you're on stable and your patch is for master
<adisbladis>
Is patching things a use-case that flakes somehow supports?
<adisbladis>
(I guess the answer is no)
<NinjaTrappeur>
__monty__: I'm not saying this workflow is superior to a overlay-based one. I just personally find it easier to cope with on a everyday basis, I like not having to edit any nix and just picking up commits to build my machine branch. I guess it's a matter of personal taste.
<NinjaTrappeur>
+1 adisbladis
<__monty__>
I'm not arguing over superiority.
<__monty__>
Just trying to find out if I'm really missing out on anything.
<__monty__>
Channels get a lot of flak but don't really seem to experience the problems attributed to them.
<__monty__>
I'm not a hardcore nixos user though.
* gchristensen
is a big fan of channels in most cases
<aanderse>
i've only ever used channels
<aanderse>
i feel like all the cool kids are using git checkouts
<sphalerite>
I use channels too
<etu>
Most of my systems use channels, but I have a few that doesn't for more granular control when things happens
vesper11 has quit [Ping timeout: 256 seconds]
vesper has joined #nixos-chat
waleee-cl has joined #nixos-chat
cjpbirkbeck has joined #nixos-chat
<srk>
infinisil: around?
<aanderse>
well if all these cool kids are using channels... maybe i'm not missing out on as much as i thought
<srk>
for me it's mostly about being able to quickly hack on my system(s) and bisect if anything goes wrong
<MichaelRaskin>
I am not sure I have ever used channels for a whole month straight
worldofpeace has left #nixos-chat ["User left"]
worldofpeace has joined #nixos-chat
<julm>
NinjaTrappeur: is there a reason why you're passing by Prometheus' API, and not the git-revision file in https://nixos.org/channels/"$channel"/git-revision ?
<NinjaTrappeur>
None ><. I wasn't aware of this endpoint. I just naively looked at status.nixos.org and used the same endpoint 🤷
<julm>
heh :P
cole-h has joined #nixos-chat
andi- has quit [Ping timeout: 244 seconds]
<julm>
adisbladis: so far I'm doing the same as you: wrapping Nixpkgs and calling applyPatches and fetchpatch to get a new Nixpkgs. This make it easy to cherry-pick Nixpkgs patches from still unmerged PR, using this URL pattern: https://github.com/NixOS/nixpkgs/pull/${PR_NUMBER}.diff
<ajs124>
free life protip: never mess with any linux routing table except default. especially not local.
<emily>
the worst part of packaging stuff for nixos is dealing with upstreams' zany ideas about software
<ajs124>
What are you trying to package?
<emily>
of course, I can say this because "the worst part of having stuff packaged for NixOS is dealing with their zany ideas about software" applies the other way around :P
<emily>
ajs124: just trying to help someone else package a Rust tool and ran into "I don't get the point of reproducable builds for anything that is not certified/tested." :(
<emily>
(they don't check-in Cargo.lock because it'd be effort to keep updated)
<ajs124>
I spent 1-2 hours fighting the amazing stuff the kurento people came up with. Then I gave up.
<Taneb>
I've tried a few times to get Oolite packaged and given up
<ajs124>
emily: amazing. I've seen a node.js project at work recently that doesn't "build" anymore, for the same reason. Noone bothered to commit a lock file.
andi- has joined #nixos-chat
<emily>
ajs124: if you follow semver the chances are lower I guess. but yeah it's a shame.
<emily>
the extent to which system-wide reproducible builds are held up by people just not really thinking it's a big deal is kind of sad
<ajs124>
Does it? I use yarn, but I guess same difference. I though it actually downloads the stuff that's in there.
<adisbladis>
ajs124: npm seems to update the lock file at every run
<adisbladis>
But I dunno if it changed. I rarely use npm.
<adisbladis>
ajs124: Ah, they added `npm ci`
<adisbladis>
So that's what you should use to actually use the lock file
<ajs124>
I think yarn install actually uses the lockfile. But I only use that stuff for projects I'm not invested in anyways.
<adisbladis>
Yarn is much more sane than npm (mostly)
<sphalerite>
emily: "are you familiar with the works-on-my-machine problem?"
<emily>
sphalerite: people have a lot of faith in semver, I guess. I mean, it's nice when it works, for sure
<emily>
sphalerite: the other counterargument was that distributions ignore the locks and share versions widely and that causes issues anyway, which, ok, fair, though that seemed more like an argument in favour of locks to me :p
<sphalerite>
emily: I don't see how semver helps with that. There's a reason that patch releases exist, and who knows how often a bug fix introduces a new bug
<emily>
well, the counterbalance is that you often want those bugfixes (security updates etc.)
<emily>
but yeah I guess you need the additional assumption "bugs go down with patch releases over time" to make it actually work out for the best, and there's still no way for a single version number to capture all bug-compatibility concerns
<cransom>
i love nixos's zany ideas about software. as an ops focused person, i'm only 1% as anxious when i do deploys compared to past lives.
<gchristensen>
<3 cransom
<{^_^}>
cransom's karma got increased to 3
<gchristensen>
same
<cransom>
i was near a decent sized puppet environment where the admins started life with `ensure => latest`. i'm sure it worked like it was supposed most of the time. when it failed, it brought down production. it was a rhel environment, it's been a while, but i don't remember those repos being cavalier with updates.
<sphalerite>
it should be easy to get the updates, but also easy to get the exact same thing as (before|someone else)
<ornxka>
not as in "i dont understand how it works" but as in "i dont understand how this leads to a working system that doesnt break all the time"
<ornxka>
are there ever times when it fails?
<sphalerite>
ornxka: none I know of, I've been using nixos since 2016
<ornxka>
wow
<ornxka>
thats pretty amazing
<sphalerite>
ornxka: well, I guess the one thing where we have a "workaround" is python packages — that's why they always have propagatedBuildInputs rather than buildInputs
<ornxka>
ahh i see
<sphalerite>
ornxka: I think niksnut did some analysis on that in his thesis as well
<infinisil>
Hm question: How do runtime deps get determined for things like tar archives?
<infinisil>
Because the compression should mess up the hashes
<sphalerite>
infinisil: in uncompressed tar archives, just like that
<sphalerite>
infinisil: in compressed tar archives, they don't!
<ornxka>
i guess the fundamental reason why the strings | grep /nix/store trick works is that for it to fail youd have to either refer to a nix path that wasnt in your inputs at all (where would you even find it? youd need nix-specific logic that would be bordering on intentional malice almost) or to refer to the system (which doesnt have anything in it and again youd need nix-specific logic to do naughty things like look in /run/current-system)
<sphalerite>
ornxka: well, you could also take the path and bitwise-negate it or something
<ornxka>
or the third option where it finds a nix store path and obscures it somehow so it doesnt show up in strings which actually seems more likely
<sphalerite>
or compress it as infinisil just suggested
<ornxka>
yeah
<sphalerite>
Thing is, our inputs aren't really adversarial
<infinisil>
Apparently this supports qcow2-compressed as a format
<sphalerite>
Even if we were packaging malware, I don't see what interest the malware would have in not getting dependencies it might need to be able to work :p
<sphalerite>
infinisil: the disk images include all the paths, so it's quite convenient that they don't depend on the paths inside
<infinisil>
Ohh
<infinisil>
That makes sense
* ornxka
make ld-linux-x86.so that literally looks through your entire hard drive to find the shared libraries it wants
<ornxka>
then it looks through your .ssh/config
<sphalerite>
ornxka: on the topic of the loader, #24844 is a bit of a pain
<ornxka>
if that could be fixed it would actually be slightly faster than standard distributions
<infinisil>
sphalerite: Ah yes, neat
<sphalerite>
both in order to include them all, and to provide a file containing the registrations for initialising the nix store
<sphalerite>
ornxka: well, they have ld.so.cache so not really I think?
<ornxka>
ahh i see
<sphalerite>
but could be about equally fast, if the longer paths don't break boundaries on CPU cache or something. I don't think an ELF header is that big though?
<srk>
proxychains default and znc support requires tor.client, maybe I'll try to improve that a bit but not sure how exactly atm
<srk>
I've asked on #znc-dev about configuring plugins as well and it looks doable - either generating .registry in module dir or there was another suggestion which doesn't rely on internal format - to use command interface via some script but that won't work with mutable = false;
<infinisil>
srk: Oh yeah I'd really like to see module config support
<infinisil>
Generating the .registry files sounds like the best plan
<infinisil>
(though it needs some encoding handling in nix)
<srk>
yes, html :D
<srk>
require%5f;auth yes
<srk>
o \
<eyJhb>
Currently doing that in my ZNC
<eyJhb>
And then just place them in the correct dir. But it is not pretty
<srk>
:D we can try to improve it ;)
<srk>
eyJhb: due to / with mutable = false, right?
<eyJhb>
srk: mutable = false; yes :D Not sure what you mean with / :|
<srk>
(due to|with) :)
<emily>
ornxka: you can think of nix's dependency scanning as analogous to conservative garbage collection
<emily>
in C, the Boehm GC will falsely keep references just because you have a bit pattern equal to their pointer; and it will miss references you convert to intptr_t and XOR with some random value, etc.
<emily>
it introduces undefined behaviour and breaks perfectly valid programs, as well as leaving around memory that could theoretically be freed... but in practice it works pretty much okay
<emily>
it just gets ugly when you have to work around it
<ornxka>
im just a bit amazed that it actually works and nobody does things like apply compression to files that contain nix store paths, etc
<eyJhb>
srk: to/with, I see, thought you meant the operator in Nix :p
<srk>
lol :D
<srk>
eyJhb: mind sharing your .registry approach?
<eyJhb>
Sure, but it is hardcoded ugly
<srk>
np, it's the only missing piece now preventing me to switch to immutable pi-bouncer :D
<pie_[bnc]>
eyJhb:
<pie_[bnc]>
"Something man-made is here
<pie_[bnc]>
Something man-made is here and it is dangerous
<pie_[bnc]>
This place is a message... and part of a system of messages... pay attention to it!
<pie_[bnc]>
This place is not a place of honor... no highly esteemed deed is commemorated here... nothing valued is here.
<pie_[bnc]>
Sending this message was important to us. We considered ourselves to be a powerful culture.
<pie_[bnc]>
What is here was dangerous and repulsive to us. This message is a warning about danger.
<pie_[bnc]>
The danger is in a particular location... it increases towards a center... the center of danger is here... of a particular size and shape, and below us.
<pie_[bnc]>
The danger is still present, in your time, as it was in ours.
<MichaelRaskin>
Why exactly you are citing the 10000-year message in full?
<gchristensen>
not sure if pie_[bnc] pasted and their client is doing a significant amount of rate-limiting or if they keep sending manually
<pie_[bnc]>
I think that was enough :P
<pie_[bnc]>
but i just realized we should start putting this in codebases
<__monty__>
I've run into blogs that no longer make much sense because the linked tweets are gone.
<__monty__>
Do they need to be *not* there though?
<gchristensen>
the idea of people going through old tweets is very weird to me, and yes, I don't want that
<MichaelRaskin>
I would say there is a lot of definitely short-expiration-date tweets, then there are some threads (by one person or multiple) that do bring context together in a less short-term way.
<pie_[bnc]>
gchristensen: ah
<pie_[bnc]>
i can totally understand wanting ephemerality
drakonis has quit [Ping timeout: 265 seconds]
drakonis has joined #nixos-chat
<aleph->
Yeah hwayne is great
<aleph->
Kinda odd the intersect of nix and lobster.rs now
qyliss has quit [Quit: bye]
qyliss has joined #nixos-chat
<sphalerite>
hahaha I think the "Update" part at the end wasn't there the last time I read that
<aleph->
Okay I'm totally wondering if I can re-add the openstack module. But just make it a wrapper around openstack images via the docker-containers module...
<aleph->
This is gonna be so hellish
endformationage has joined #nixos-chat
<armin>
i don't quite get what guix is about. is it of interest to someone who already runs nixos?
<__monty__>
armin: Three distinguishing features: GNU, Guile and a focus on reproducibility with Mes and such.
<elvishjerricco>
Anyone here use ZFS native encryption for root? Experience reports?
<emily>
elvishjerricco: experience report: it works, it's good, I'm glad I don't have to deal with LVM or LUKS
<elvishjerricco>
Nice. I'm thinking about switching.
<adisbladis>
elvishjerricco: So far so good
<adisbladis>
Been running on zfs native crypto since before it was officially released
<adisbladis>
One annoying thing was the on-disk format change
<emily>
elvishjerricco: I have it set up on my server unlocked via initrd ssh too, works great
<adisbladis>
But that's what you get as an early adopter
<adisbladis>
Since it went stable no complaints at all
<elvishjerricco>
One annoying thing is that it interferes with my janky master plan for passwordless reboots via kexec.
<elvishjerricco>
My desktop is currently configured so grub unlocks LUKS itself, and boots from ZFS. On the dataset, there's an initrd.keys.gz that grub appends so the kernel doesn't re-ask for the password. Using that keys.gz, I can kexec reboot to a new kernel without re-entering the password.
<emily>
you can just do the same trick and feed it to zfs load-keys, can't you?
<elvishjerricco>
emily: Well grub can't read zfs encryption, so the kernel has to be unencrypted. Then stage-1 asks for the password and that's that. Kexec-ing will run stage-1, which asks for a password
<elvishjerricco>
Hadn't seen that. Thanks
<emily>
elvishjerricco: I mean worst case you can do something isomorphic to what I do for initrd ssh:
<emily>
the keys just have to be loaded once `zfs load-key` terminates, it doesn't have to be because that process loaded the keys :P
<elvishjerricco>
Lol gross, but effective
<elvishjerricco>
emily: Problem is, the key isn't stored anywhere this way, and you can't ask zfs to dump the key like you can with luks
parsley936 has quit [Remote host closed the connection]
parsley936 has joined #nixos-chat
<emily>
right. well, you just need somewhere to stash the keys temporarily, I guess. you can probably arrange some way for a bit of memory to survive post-kexec, not sure if you can do it in a way that isn't gross. if you have some temporary storage you trust you can reliably erase then you could stash the keys there
<emily>
I think what you really want if you want passwordless reboots with an encrypted FS is to derive the key from a TPM or whatever
<elvishjerricco>
emily: Actually, the encrypted dataset could just contain a copy of the passphrase, and then the kexec prepare service could create an initrd on tmpfs that contains the passphrase, with some code that somehow causes stage-1 to use it
<elvishjerricco>
But I don't like having my actual passphrase that I type stored on disk, even in encrypted form... I don't even want the kernel to be able to know that passphrase after the master key is decrypted.
<elvishjerricco>
Too bad ZFS encryption doesn't have key slots :/
<emily>
elvishjerricco: you can kexec from an initrd on tmpfs? wild
<emily>
kernel just copies it on load I guess?
<emily>
anyway, you can avoid it being on disk by stashing it in the initramfs when you load it at boot, I guess
<emily>
it could still get paged out to swap I suppose
<emily>
(and yeah, the usual risks of having it exposed to userspace like that)
<emily>
er, in the initramfs → in a tmpfs
<elvishjerricco>
emily: kexec works by loading a kernel and an initrd into memory in kernel space. The initrd file is just read into memory when you load it. Then the kernel puts the new kernel and initrd in the right places and jumps to it.
<emily>
I think the kernel has generic secrets machinery, maybe you could just stash it in there, probably better than keeping it in tmpfs the whole time?
<elvishjerricco>
emily: I could also have the key for the zfs dataset actually not be my passphrase, but a random key file. Then store that key file encrypted with something else using my passphrase where stage-1 can access it. Then store a copy of that key on the encrypted dataset for use by the kexec preparation.
<elvishjerricco>
The key to unlock the disk is still stored on disk, but the passphrase needed for cold boot isn't
<emily>
elvishjerricco: is this for a server, or a laptop/desktop?
<emily>
I think that distinction is extremely academic unless you have a plan to defend against the threat model of a screwdriver and taking the disk out
<elvishjerricco>
emily: Planing to use this on all three types :P
<elvishjerricco>
emily: But what do you mean? I'm safe from the disk being stolen by nature of it being encrypted
<cole-h>
What if it's stolen while unlocked
<emily>
elvishjerricco: I mean, your whole threat model is about bad things happening when it's unlocked, so my point was that if someone gets their hands on the actual disk encryption key, it doesn't matter that your bootloader requires a passphrase because they can just take the disk out
<emily>
even in the absence of physical attacks you need a pretty strongly verified boot chain
<elvishjerricco>
cole-h: That's definitely an issue for a laptop. Hopefully software locks keep them out so they have to find a way to steal data from RAM via hardware
<emily>
if you have secure boot disabled, or someone can just init=/bin/sh, or one of a billion other things, it doesn't matter what your initrd happy-path looks like any more
<cole-h>
I'll probably come back and read this conversation at some point since it sounds interesting... elvishjerricco: if you figure this out, I'd certainly be interested in seeing what you did (either raw code, or a blog post) ;)
<emily>
re software locks: fyi I have gotten gnome's lock screen to crash and leave me in my session by keymashing, within like, the last few years, just so you know :P
<emily>
I strongly recommend using at least physlock or similar if you're going to suspend rather than hibernate
<emily>
iirc google has their own locker just because gdm's is such a piece of crap >_>
<qyliss>
wow
<emily>
other DEs may be better off there, but generally speaking I don't place a huge amount of trust in "let's just draw a GUI prompt window over everything and hope for the best" locker designs to begin with
<elvishjerricco>
emily: The idea about not storing the passhprase on disk is just that what I type on the keyboard should only be susceptible to keyloggers.
<elvishjerricco>
And yea, I use xsecurelock. Though 20.03 seems to have somewhat broken for me. It says "incompatible compositor" even though I don't use a compositor
<elvishjerricco>
Still locks. Just with a big warning message behind it
<elvishjerricco>
But I do see your point
<emily>
nothing says secure like a big warning message
<emily>
maybe I should write wayscreenlock
<elvishjerricco>
yuuup. Fixing that is probably going to be the next thing I do
<emily>
Xorg isn't exactly the nicest attack surface for this in the first place
<emily>
it'd be nice to have something that at least gave you the basic physlock guarantees of switchiing to an entirely different session/VT/...
<elvishjerricco>
Man I wish I could get physlock to do what I want. I'd definitely use it instead
<emily>
though honestly if I invested in making my locking setup much more secure I'd be focusing on auto-hibernating after a current period, since physlock works ok for me
<elvishjerricco>
But it doesn't let the display sleep
<emily>
I just always suspend when locking
<elvishjerricco>
I leave my desktop up constantly. I SSH into it all the time both from the other room and from another state
<emily>
even physlock is slightly brittle: it'll lock before suspending, which is good, but then if you unlock it before it suspends you'll unsuspend into an unlocked state :')
<emily>
cole-h: mine would look more like "start another compositor entirely, switch over to that VT with logind, keep locked on it no matter what until we decide to let go"
<emily>
your normal compositor doesn't even get to look at the inputs or display stuff while locked
<cole-h>
emily: I see. Be sure to post it here if you ever work on it, I'd certainly be interested in looking at the internals at least
<emily>
sure ^^ most of the nitty-gritty stuff already exists in physlock, https://github.com/muennich/physlock, it'd basically just be a matter of bolting that to an additional wayland compositor etc. rather than doing a simple PAM thing
<MichaelRaskin>
I actually have the switch-and-hold part, but then you want to make sure you do not get locked into VT63
<elvishjerricco>
emily: Is it possible to do that with X currently?
<MichaelRaskin>
You don't even care what it is, to be honest
<emily>
MichaelRaskin: I mean, do you want to make sure of that? it's a security vs. availability tradeoff
<emily>
if you're using an elaborate defence-in-depth lock mechanism, you'd probably rather require a reboot than risk an exploit letting a malicious user in
__monty__ has quit [Quit: leaving]
<MichaelRaskin>
Then you'd better have a good physical-security defences against malicious USB, too…
<emily>
(see also the analogy in the physical world, where there are plenty of quite safe locks that "deny on fail", but nobody wants them because availability takes priority over security, you'd rather have a vulnerable lock than get locked out of your home)
<emily>
of course
<MichaelRaskin>
I mean, it is pretty hard to build the system so resilient against physical-access attacks that it is natural to not care if you get locked out
<MichaelRaskin>
But then it is independent of Wayland/X/whatever
<emily>
that's kinda the "in-depth" part of defence-in-depth; but the lock screen is about the most important attack surface there is in terms of an attacker with (even brief) physical access, so...
<emily>
sure, but in that case why bother with fancy vt-switch mechanics? you can just use gdm and let it crash
<emily>
or not bother locking at all
<emily>
my current lock setup is actually hilariously insecure because I can unlock PAM with my u2f key
<emily>
waiting on pam_u2f to support FIDO2 to fix that...
<emily>
(so I can use a PIN)
<cole-h>
What's insecure about using u2f to unlock PAM? Maybe I misunderstood, but that sounds pretty OK to me
<MichaelRaskin>
Well, I use XScreenSaver as a locker against very cheap attacks, and then VT-switch is for completely different aims (simplest way to shutdown is vt-switch-to-prove-presence)
<emily>
elvishjerricco: sure, nothing stops you running multiple Xorgs on several VTs
<emily>
elvishjerricco: I've done it for games and stuff in the past
<emily>
cole-h: because my yubikey nano lives inside my laptop's USB port :P
<elvishjerricco>
emily: I have no idea how to do that :P
<cole-h>
emily: Oh LOL
<emily>
elvishjerricco: ctrl-alt-f5, startx
<MichaelRaskin>
emily: if you want VT-switch, you do not want anything like full wayland on the target
<MichaelRaskin>
Just VT-switch, lock, and require a succesful login as unlock user.
<emily>
MichaelRaskin: I mean you can just use DRM directly but the basic wayland client-server protocol is pretty much what you'd want for privilege separation between "talks to DRM" and "services user requests"
<emily>
so I think a compositor-client split actually makes sense
<emily>
of course you want a simple-as-possible "kiosk" compositor
<MichaelRaskin>
You wan fbcon and console login
<emily>
(such privsep also reduces the risk of, e.g. using an existing toolkit, or IMEs, or such, in the prompt, because the process with that code doesn't have unlock rights, just forwards the authentication data)
<MichaelRaskin>
Well, I need a more general flow (and do not want locking like that), so physlock is completely useless to me and I never looked at it
<MichaelRaskin>
Maybe you do need it on systemd systems where you cannot just spawn login on VT63 without some session dance
<emily>
(in fact, CONFIG_FB/CONFIG_VT are well-known awful legacy blobs that probably have their own pile of security issues, so doing a Wayland thing over that could well result in increased overall system security)
<emily>
(kmscon/systemd-consoled are dead though, so running with CONFIG_VT=n is kind of an untenable hassle in practice)
<MichaelRaskin>
Well, your entire idea is based on the console switch and console switch locking.
<emily>
logind orchestrates the session switching stuff in a CONFIG_VT=n setup
<evelyn>
hmm my debian desktop just puts me back on lightdm when locking the screen..
<evelyn>
I'm not sure if it's just acting as a screen locker like xscreensavver though
<MichaelRaskin>
Well, of bad kernel code and good systemd code I would trust kernel
<emily>
pretty sure the kernel is still involved on some level, but even kernel devs are scared of the fb code