On 06/15/2016 02:36 PM, Chris Murphy wrote: > On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >> On 06/15/2016 01:09 PM, Michael Catanzaro wrote: >>> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote: >>>> Of course, this comes with its own headaches, since of course if you >>>> are using >>>> an encrypted drive, you need to enter your password twice: once to >>>> start the >>>> update and once for the post-update reboot. A while ago I was working >>>> on a patch >>>> to PackageKit that would skip the second reboot and just `systemd >>>> isolate >>>> default.target` after the upgrade unless the kernel (or other early >>>> boot package >>>> like dracut) was updated. I never finished it, but I could try to dig >>>> it out and >>>> pass it on to someone who is interested in continuing it. >>> >>> If anyone wants to pick up this work, that would be hugely appreciated, >>> as it would allow us to enable full disk encryption by default. >>> >> >> Well, as I alluded to in another post, I think the disk encryption case is >> probably better solved by investing in the development and stabilization of >> Tang[1]. Then you would not need to enter the password manually at all. >> >> [1] https://github.com/npmccallum/tang/blob/master/README.md > > I see that it's solving a problem, but that problem isn't everyone's > problem, and the solution doesn't solve everyone's problem. It > requires a tang server, so how does this work for Workstation users? > Where is this server? > > I go to a random coffee shop, I'm on a totally different network, or I > travel a lot and I'm on many different networks, how does this scale? > One thing I've been thinkin about is building a tang server as an Android application, so that you can decrypt your system simply by having the computer make a temporary ad-hoc connection to your cellphone. If it's not within WiFI range, the computer doesn't unlock. But yes, the main use-case for Tang is datacenters that don't want their drives unencrypted at rest (in case they get thrown out or returned for service), but don't want an interactive prompt when they need to do a rolling update requiring a reboot. > For a computer that needs to update an encrypted disk with the current > pk offline update mechanism means networking all has to be baked into > the initramfs and autoconfiguring in order for the disk to be > decrypted and updates applied. > That makes me nervous as storing the key in something that can survive a reboot means that the key is potentially recoverable (such as if the machine gets powered off before the second reboot). > I still think the update needs to happen on logout without first > rebooting, and only rebooting after the update is successfully > applied. If it were a scheduled/delayed update, then the default > behavior would be shutdown after the update is applied rather than > reboot. > > Something like that. > I think ostree is a better fit for you, then. It's atomic; you know before the reboot whether the packages will update cleanly or not (and you have a full rollback if something in runtime is broken). It requires no special mode to prep the update, either.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
