<abathur>
gchristensen LnL reading over apfs_volume.rb does make me wonder whether the people who've reported back on encrypting the store volume and using keychain to supply the credential were putting it in the login or system keychains, and (if no one reporting trouble used the system chain) whether there's any delta between when keychain itself and the login/system keychains are available
hmpffff has quit [Quit: nchrrrr…]
<eraserhd>
hmm, I just entered the value when prompted on first reboot and clicked the "store in keychain" button, and it continues to work without incident... apparently it is in my login keychain.
<abathur>
are you using any nix-managed apps/shells that restore on reboot?
<eraserhd>
My login shell, according to System Preferences, is /run/current-system/sw/bin/zsh
<eraserhd>
I have at least one nix-darwin launch daemon that runs nix-install autossh. It's possible that it hasn't been starting and I don't know.
<eraserhd>
s/nix-install/nix-installed/
<LnL>
abathur: I think I'm missing something but how is the keychain actually used here (read)?
<abathur>
eraserhd worth looking; I can't recall if there's a way to see what it's doing if you don't already log it, but it's not hard to add logging for it; IIRC the cases I've heard where it caused issues are tabs/windows restoring in a terminal with a Nix-managed shell that isn't available yet (and thus just fails and kills the session in each tab), or restoring an entire Nix-managed .app
<abathur>
LnL in our case, or in the ruby file gc linked?
<eraserhd>
I'm prompted for my password before login, to unlock the system filesystem. I'm not prompted again to unlock a filesystem AFAIK, but I'm prompted to actually log in after the machine is booted. it seems weird if the Nix volume isn't mounted at that point.
<eraserhd>
This is a corporate managed laptop, though, so perhaps they have some config here that I don't know about.
<abathur>
not that I'm exactly clear on either; I haven't picked the ruby apart that far, but I do see that it's doing something with the system keychain and it made me wonder if the problem reports we've gotten back would be ameliorated by adding the decryption password to the system chain
<abathur>
I suppose if I get bored enough I can use my spare catalina system to try to intentionally generate an error in a semi-reliable way
<qbit>
LnL ty!
philr_ has quit [Ping timeout: 272 seconds]
<LnL>
did you get unstuck?
<qbit>
ya, i can install things now :D
<LnL>
great :)
<LnL>
abathur: yeah, took a quick look and don't really understand what's going on
burkelibbey_ has joined #nix-darwin
wildsebastian has quit [Ping timeout: 240 seconds]
<gchristensen>
oh hey bodgix_
<gchristensen>
oops
<burkelibbey_>
I was summoned by gchristensen and have successfully defeated NickServ
<gchristensen>
burkelibbey_:
<burkelibbey_>
(sorta)
<abathur>
ha
<qbit>
hm, maybe not - i installed the cacert package but things are still erroring out with the same message
<burkelibbey_>
Short answer when you put the key in the System Keychain, Apple seems to pull it out on boot to unlock the volume
<burkelibbey_>
But happy to answer specifics
<abathur>
nod
<gchristensen>
please :)
<gchristensen>
we'd really like the default automatic install to do the right thing
<LnL>
ah I see
<abathur>
I guess my main ones are whether you saw errors using the login chain and are confident using the system chain overcame them?
wildsebastian has joined #nix-darwin
<LnL>
I still really don't like the idea of having the installer generate encryption keys on it's own tho
<burkelibbey_>
Yes-ish: Using the login keychain meant that the volume wouldn't be mounted until partway through the user login process. So if, for example, the user has a terminal set to run on login, it could get into a weird state with an incomplete process environment if it's generating from ~/.nix-defexpr. With the key in the System keychain, it's mounted before login
<burkelibbey_>
I mean, it could ask whether you want filevault enabled on the volume, and then whether it should generate its own password
<gchristensen>
burkelibbey_: mabye you and your team would be interested in revamping the macos installer
<gchristensen>
with us
<burkelibbey_>
for us of course we're comfortable doing this for our users but I can see how the calculus might be different in the external world
<LnL>
yeah for your case it makes total sense
<burkelibbey_>
yeah, I'd be happy to lend a hand on this, I could probably even pass it off to someone else that's trying to ramp up on Nix right now but is one of the top 2 authors of dev.
<LnL>
also does this still requires a dialog box at some point right?
<burkelibbey_>
I don't recall 100%—I know the login keychain would prompt on first login then you'd click Always Allow but I *think* the System keychain doesn't prompt you
<burkelibbey_>
it just requires sudo to write into of course, as does a lot of these diskutil gymnastics
<LnL>
because another usecase to keep in mind is unattended installs
<abathur>
nod
<LnL>
having your build infra not startup because of a dialog box is undesirable
<LnL>
and disk encryption is a totally different tradeoff there most likely
<burkelibbey_>
agreed. one thing we could do is detect filevault status on the root disk and mirror that
<burkelibbey_>
it would be a rare case that a user wouldn't want the same behaviour
<LnL>
that's what we did already
<burkelibbey_>
ok cool
<LnL>
but the current behaviour is old hw -> fail, new hw -> warn
<LnL>
so all this keychain stuff is totally up to the user (post install) right now
<burkelibbey_>
yeah if we could make it a simple enough incantation and message it clearly enough to toggle on filevault, I can imagine that being a good follow-up step
<LnL>
bigger picture there are also a few more issues like nix#3616 btw
<{^_^}>
https://github.com/NixOS/nix/issues/3616 (by amckinlay, 2 days ago, open): macOS updates often break nix installation (updates replace path-hooks on multi-user install)
<burkelibbey_>
I like the idea of (by default) generating a passphrase for the user and messaging that that's what we're doing, with an easy way to provide their own.
<burkelibbey_>
ah, we don't run into that because we moved nix environment init into our dev tool because upstream didn't want it to be idempotent 😂
<gchristensen>
I kind of think making the instaler not part of Nix itself would be a good thing
peel has quit [Ping timeout: 252 seconds]
<gchristensen>
to make it really fast to iterate on
<burkelibbey_>
but yes, macOS constantly overwrites /etc stuff
<LnL>
yeah that's another reason I don't like the idea of all this installer cruft
<LnL>
feels weird polluting the nix repo with all that
<abathur>
anyone have a sense of what conditions/motivations would lead someone to *want* a bespoke password for the store volume?
<burkelibbey_>
`ruby -rsecurerandom -e 'puts SecureRandom.hex(32)'` works pretty well and I'm not sure anyone would mistrust it if we messaged what we were doing
<qbit>
fixed by switching to single user install \o/
<LnL>
gchristensen: also all the installer issues with idempotency, etc. really make me think it shouldn't be an installer but rather a nix managed install (think using some of the ideas from the module system)
<gchristensen>
interestin,g yeah
peel has joined #nix-darwin
<burkelibbey_>
(I'd say we should just rip the task/dep satisfier out of dev to build a more idempotent nix installer if not for the fact that it would require bootstrapping ruby first)
<abathur>
heh
<abathur>
well
angerman has joined #nix-darwin
<burkelibbey_>
`./nix-install up` 😂
<abathur>
this thread I'm pulling on for the catalina performance issue was already making me wonder about the best way to message something additional that should maybe be a little stickier than just a suggestion during the installer
<abathur>
something more like nix doctor, but also more discoverable? dunno
wildsebastian has quit [Ping timeout: 244 seconds]
<LnL>
well whatever we want to use just could be part of the install closure
<LnL>
that's better than relying on random system stuff like we do now
<LnL>
and might be possible to strip that down quite a lot like what we do for the stdenv bootstrapping
<abathur>
still chewing on it; installer message is good and the right time but also ephemeral and not necessarily read/understood by new users--easy to forget if you're anxious to start playing around, etc; `nix doctor` is also a good place but many users probably won't find it until they have a problem; maybe running nix doctor or something like it could be part of the standard install process
<LnL>
alternative is the nix upgrade-nix direction, use a binary instead of scripts and statically link everything in
wildsebastian has joined #nix-darwin
<burkelibbey_>
(I've literally never run `nix doctor`)
<abathur>
I hadn't until the other day
<LnL>
I mainly added that to make debugging of protocol mismatches easier
<LnL>
but it does a few other things
<abathur>
I guess a lot of things can also be treated as bolt-on or post-install
<LnL>
true, once we have a working nix-build (even tho nothing else is setup) dependencies become much less of a problem
<abathur>
right? like all we *need* to do to install Nix is create the volume encrypted or no--is it a problem for users with an FDE policy if there's a follow-up script post-install that immediately gives you a chance to encrypt (and do things like set up the Dev Tools exemption?)
<abathur>
I guess the unexpected /etc/{bash,zsh}rc overwrites are another thing an occasional auto-health-check process could help notice and at least message if not correct, though I'm not sure when/how it should run and how it should report to the user
hmpffff has joined #nix-darwin
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nix-darwin
hmpffff has quit [Quit: nchrrrr…]
hmpffff has joined #nix-darwin
Chiliparrot has joined #nix-darwin
Chiliparrot has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
hmpffff has quit [Quit: nchrrrr…]
__monty__ has quit [Quit: leaving]
hmpffff has joined #nix-darwin
hmpffff has quit [Quit: nchrrrr…]
burkelibbey_ has quit [Quit: Connection closed for inactivity]