<LnL>
just heard about project Kalamata, that's going to be fun...
<domenkozar[m]>
there are not enough quotes to quote fun
<LnL>
:p
<gchristensen>
maybe at that point we decide it is okay to run it on arm
<gchristensen>
non-mac arm
<domenkozar[m]>
that would be packet.net scale
<gchristensen>
exactly
<domenkozar[m]>
they added v3 instances
<domenkozar[m]>
I'm still hoping for one that doesn't cost 300$ per month :D
<gchristensen>
hehe
<domenkozar[m]>
well, tiny is 277$
hmpffff_ has quit [Read error: Connection reset by peer]
hmpffff has joined #nix-darwin
eraserhd2 is now known as eraserhd
clever has joined #nix-darwin
philr__ has quit [Ping timeout: 272 seconds]
<evelyn>
wow that latest comment on /that/ issue: 'And that's still ridiculously complicated. I would say that your software project is failing if it requires reading a wall of text and issuing lots of volume-based commands just to get a basic installation complete. Major fail in fact.'
<evelyn>
does he want a refund or something
<gchristensen>
probably
<gchristensen>
(but really, don't be a jerk back -- no need)
<evelyn>
I think it's probably not wwrong but it is such a strange comment
<LnL>
if anybody's up for going over the docs / error messages
<LnL>
that's basically the only thing holding it back for me
<abathur>
LnL how do you mean? grammar/phrasing? more fundamental?
<LnL>
abathur: especially the filevault error isn't very actionable right now
<abathur>
right, which is basically where the complaint got testy I think
<cransom>
wait, we can get refunds?
<abathur>
yes
<abathur>
just uh
<abathur>
rm -rf /nix? right?
<abathur>
LnL I think there may be a question of higher-level goals here that isn't getting communicated or documented?
<abathur>
it seems suboptimal to me to just tell people that they're on their own, if they're running filevault, since the installer often suggests it to me (I haven't figured out for certain when it does/doesn't--it doesn't do it every time)
<abathur>
so it doesn't seem like a given to me that any given FV user is at all prepared to answer the next-step questions and choose the right option
<abathur>
but I also don't understand if we just want some documentation here as a stopgap for a later update when we try to actually solve the issue at install
<abathur>
or if this *is* the long term solution
<abathur>
which would have some bearing on how thoroughly it is documented
<cransom>
it doesn't help that nix is severely un-apple like from the beginning. to the casual observers, it's super unfriendly.
<LnL>
let me try to braindump
<LnL>
not going to mention moving /nix that's a different topic
<abathur>
LnL: I don't mean to say you have to have answers to all of that; I'm just spitting out some questions I've had percolating from watching it develop, and having done an unencrypted install recently
<LnL>
1. symlink is undesirable for builds, might be ok in very specific cases but not a general solution so volume is the only other option
<abathur>
and wanting to have, longer term, a fairly braindead non-interactive solution for using filevault if it's possible for one to exist
<evelyn>
maybbe the apfsctl program referenced in the pull request will arrivve sometime
<abathur>
nod
<LnL>
2. (it seems?) apfs doesn't allow sharing of the root encryption for other volumes so there's no (extra) encryption by default
<LnL>
3. machines with a T2 chip have encryption at rest which resolves most of the concerns but older machines can leak data or more importantly the store could be tampered with
<LnL>
4. enabling encryption requires a passphrase which is something the installer shouldn't set or manage for you transparently IMHO
<abathur>
yeah, I almost wrote something along the lines of #2 in the thread; all we really want is a button we can sudo-push that says give me a volume encrypted however the system/data volumes are and mounted at the same time
<LnL>
implicitly*
<evelyn>
hmm this guy on the issue now seems really pissed :/
<LnL>
5. even with a passphrase how to unlock the volume on boot/login isn't very clear to me yet and those options all have downsides which should be considered
<evelyn>
I still am confused about what the encryption at rest on T2 macs means in practice... if you don't need a password to unlock it it only seems to protect against someone removeing the hard drive (or soldered flash storage) , not someone booting to recovery?
<abathur>
evelyn: I think mostly yeah, though they have added a new wrinkle (I'm not sure if this is new hardware? new to catalina?) where, if you have find my mac on, you need to be able to log into a device account to get into recovery?
<abathur>
LnL yeah; it was roughly my impression from following that we lacked confidence in any one solution
<abathur>
lol
<LnL>
ideally we'd use 2, that makes the most senss
<LnL>
just use whatever everything else is encrypted (or not) with
<abathur>
yeah, it seems like the only sane default decision if there's a way to do it
<abathur>
otherwise, lunaticare's inquiry about an interactive script, but with flag options to support pre-specifying for unattended install, might be plausible
<abathur>
though I don't know how fragile it'll prove
<abathur>
it'd suck if it's constantly breaking and accumulating conditions
<LnL>
exactly that's why I'd just like to leave that to the user
<LnL>
the installer already handles using an existing volume so it's only that part you'd have to do yourself
<abathur>
oh, well, I forgot, I guess there's also one other saneish default
<abathur>
which is adding an unencrypted volume
<LnL>
^ the following will be perfectly happy to install on an unencrypted volume
<LnL>
but just doing that by default would be pretty bad
<LnL>
but yeah that would make it easy
<abathur>
if it was quiet I guess; what if the general UX flow of a completely naive install was like...
<LnL>
I personally think encryption is a bad argument for leaking data given that the store is completely world readable
<LnL>
but tampering is valid and there's nothing within nix which protects against that once paths are registered
<abathur>
curl nix | sh -> message about nix needing a new volume on macOS, which tells you to either go make an encrypted volume <link>, or re-run with --create-unencrypted-volume
<abathur>
and then, there's explicit consent forever built into the command, even if you go stick it in a script, about what it does?
<abathur>
maybe even more verbose
<abathur>
--create-unencrypted-nix-store-volume
<LnL>
maybe, alltho doesn't feel all that different to using an existing one
<abathur>
?
__monty__ has quit [Quit: leaving]
johnw has joined #nix-darwin
<LnL>
the commands I posted earlier
<abathur>
not all that different; but it would increase the coverage golden path for anyone 1.) already using an unencrypted volume, or 2.) using an en
<abathur>
*coverage of the
<abathur>
2.) using an ecrypted volume but doesn't feel the need to encrypt /nix, and maybe also 3.) is using an encrypted volume and would like to encrypt /nix but can handle it later
<abathur>
in a way that's semantic and sanctioned
<abathur>
i.e., if they go stick the flag in a script, they (hopefully) don't have to think about whether it'll still be the right thing to do on 10.16
<abathur>
remaining outliers would be some mix of people who find leaving it unencrypted so unacceptable that they're willing to suffer a little for it; I think it's easier to give that slice of people the right kind of documentation than if the outliers are likely to include "any macOS user who thought encryption sounded like a great idea on the FileVault step of the macOS installer"
mbrgm_ has joined #nix-darwin
mbrgm has quit [Ping timeout: 272 seconds]
mbrgm_ is now known as mbrgm
<evelyn>
does the installer now have the option of enabling it? I recently reverted to Mojave (Catalina had... problems) and didn't have that.
philr__ has joined #nix-darwin
<abathur>
the official installer hasn't been updated yet