<abathur>
pulling out 2 comments from emily that I haven't addressed since they're at risk of getting snowed under: "you probably want to add the UUID to the two fields that macOS adds it by default when storing a disk encryption password in the keyring" and "consider case-sensitive apfs"
<abathur>
I don't have any strong opinion on the 2nd. I will note that this isn't currently always forcing a volume; if the root is writable, it does still just create the directory. I actually did *try* just adding the volume in CI @ https://travis-ci.com/github/nix-community/nix-travis-ci/builds/191788162, but all of the jobs before 10.14 just failed.
<abathur>
(failed to install, sorry--all of those jobs failed to run clean)
<abathur>
emily curious about your reasoning on the UUIDs
<emily>
I'm pretty sure the keychain-based automount machinery that runs e.g. at login looks up by UUID
<emily>
and it's how the passphrases are stored in the keychain if you just enter it to be remembered in the actual macOS UI
<emily>
that one shopify installer .rb has the complete `security` commands to replicate the native keychain entries
<emily>
can't find the link off the top of my head unfortunately
<antifuchs>
I wonder if symlinks on an insensitive volume to a case sensitive volume is going to break stuff
<abathur>
emily it's not clear to me whether or not (and for what reasons) we should emulate a native keychain entry, when we are not?
<abathur>
I'm also generally fuzzy on all of the freaking names and options security leaves us, many of which aren't exposed anywhere in the keychain access app itself
<emily>
I guess I just see the service as a hack to make the mounting happen earlier, and "ideally" we'd be able to reuse as much of the existing diskarbitrationd fstab/Keychain mounting logic as possible, if only it didn't run too late in the login
<emily>
it seems better that if you disable the service, the /nix volume comes up the same but merely too late
<emily>
than for it to not come up at all
<emily>
so I think leaving it in /etc/fstab, using the same format for the `security` entry, etc., makes sense; that's why I used keychain rather than a file in /etc to begin with, since it's what the OS uses natively
<emily>
(I mean, part of this is probably path-dependence: the Shopify installer thing convinced me that everything might just work if you got things in the right keychain, which unfortunately didn't turn out to be the case)
<abathur>
yeah
<abathur>
I'm not very ideological about them, though I am a little lazy (avoiding the work of finding the UUID if we aren't really using it); I mostly just didn't know what the entries were "for", so I just stuck one thing in all of the slots to keep moving and hoped others would have stronger opinions
<abathur>
I did change it from Nix Store to Nix Volume, I think I saw you comment on that once :)
<abathur>
I haven't really tried to represent it in the values yet, but I ask because I like leaving clear fingerprints that indicate where something came from, especially if they're likely to end up in the cruft someone has to sift through when they move systems; not really sure what's "right"
<abathur>
I guess my ideal case would be mirroring sytem conventions well enough that it works automagically anywhere we think it should, but flaunting them if/where we can to leave fingerprints
<emily>
fwiw diskutil has a flag to output as plist
<emily>
unfortunately plist manipulation in bash is really painful (xpath(1) is probably your best bet)
<antifuchs>
I think these days, `plutil` can probably do some key/value extractions... but it *is* a pain
<emily>
last time I tried it can only output to files, not stdout :/
<abathur>
yeah, I'm aware, we already use the plist form in 2 places in the volume script, but it's still a visit to the dentist... aside: xpath has a flag change in big sur, so if you depend on it you'll either need a wrapper or conditional code to handle invocations cleanly across them
<emily>
lovely
<abathur>
I've taken to using `xmllint --xpath` instead of xpath
<emily>
I rejected it because it was way too slow
<emily>
I mean, not *slow* slow, but "why does this take so long to spawn in my simple mount script, oh it's probably starting a JVM or something"
<emily>
(originally I was trying to write a script that scans /etc/fstab to determine your nix volume name before I decided that was dumb)
<abathur>
yeah
<abathur>
I'm a little chuffed by the unnecessary CLI api breaks
<abathur>
add a command with the new API and wrap the existing if you must make big breaking changes to stuff that's in scripts that do important things and may go breaking systems if they misbehave >:[
<emily>
well you know if this wasn't a shell script... :P
<emily>
admittedly I don't actually know what the API is like to talk to diskarbitrationd and the like directly
<LnL>
ee
Chiliparrot has joined #nix-darwin
ProofTechnique has quit [Ping timeout: 272 seconds]
<abathur>
extra synthetic because I had to do some weird stuff to enable filevault in CI, and synthetic stitching doesn't seem to work right after enabling it, so the FDE builds run create-darwin-volume.sh separately before enabling fde
<abathur>
also of course doesn't really demonstrate the key feature...
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
supersandro2000 has quit [Disconnected by services]