I think the point of this technique is to be able to leave the machine locked on cold boot, but to be able to e.g. unlock it, put it to sleep, and go on vacation; and then, if you need to remotely reboot it, you can reboot it in such a way that it stays unlocked on next boot, rather than reverting to locked.

Generally I have used fdesetup to do remote OS upgrades: do this just before an OS upgrade so that on reboot I can still log in.

It's still a little bit like putting your jewelry in a safe, and leaving the key on top of the safe.

I mean, I assume you'd set the unlock-on-reboot flag, and then immediately reboot — at which point the unlock-on-reboot flag gets automatically unset.

So, sure, it's a bit like leaving the key on top of the safe... while you have the safe open. Which isn't all that odd.

No, the scenario was power outage at an unknown time in the future, not immediate reboot.

When it comes to disk encryption, at least in the home, the threat model isn't somebody sitting around in your home finding a way to exfiltrate the currently-unlocked filesystem; It's someone taking the computer or the drive with them and leaving.

In your analogy, the key atop the vault vanishes as soon as the vault is moved from its location (loses power).

If that was the case (maybe it is, I don’t know), then how does the proposed solution help against power outages, which was asked for?

That wasn’t what was asked for. The original reason given was to require a password on cold boot, but not require a password when rebooting e.g. for an OS update

Well, you've asked me to quote in another subthread, I did. Since I don't fully get what you're referring to now, can you please quote?

It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.

Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.

This only puts the key in NVRAM until the next restart - so if you run it just before you restart an attacker would have to happen to grab the device in those few minutes.

The stated problem was power outages. I did not verify the syntax of the proposed solution, but -1 looks like it disables the delay. So, indefinitely until the next reboot? Which, if the key is indeed saved in NVRAM (I don’t know), means someone can take the machine and have it unlocked at their destination.

It used to be NVRAM at least, but that was before the integrated Secure Enclave. Now it could in theory store it there and only unlock if the boot chain is validated (similar to the automatic TPM-based unlock that Windows uses by default).

Right, but my point was, if the idea is to do this to have an automatic unlock on power outages (and if this persists across power outages), it’s not just a few minutes, it’s indefinitely.

You’re going to have to quote that the stated problem was power outages. The first comment in this thread was taking about how the linked article solves the power outage problem.

But the sub-thread about using the existing utils is only for solving the unlock on reboot problem, and explicitly not solving the cold boot unlock problem.

First comment:

> So you're saying i can now have a fully remote mac mini server with auto-reboot on power outage without the need to physically log ...

Reply:

> You can also do this: [...] -delayminutes -1 [...] which will make the computer auto login to the chosen account on next reboot, without having to type in a password. Only lasts once. Has obvious security downsides though but that might be fine.

Even though I haven't checked, the "-delayminutes -1" very much sounds to me like it disables the automated reboot, so it waits until the machine reboots for other reasons. Given this and given that it is a direct reply, I personally took it as another solution to the power outage problem, the "reboot" in question actually being a cold boot due to the power outage.

Note that I haven't verified whether this works after removing power.