On Wed, Jun 15, 2016 at 12:43 PM, Stephen Gallagher <sgall...@redhat.com> wrote: > On 06/15/2016 02:36 PM, Chris Murphy wrote: >> On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher <sgall...@redhat.com> >> 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.
OK fine, but the context is doing pk offline updates. If the system has an encrypted disk, it needs an initramfs that brings up networking in order to find the tang server on my cell phone. My laptop definitely does not have network access at all in the system-update.target. >> 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'm not suggesting storing the key in the initramfs. I'm suggesting networking needs to be brought up in the initramfs to find the tang server in order to decrypt the drive. That's a substantially different initramfs than we currently have as far as I'm aware. > >> 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. What? Why does this suddenly need a completely different deployment system to do something so basic? In particular one that's not yet really ready for prime time. Windows and macOS both do updates on logout and then reboot. They do not reboot and then do updates, and neither of them have the benefit of rpm-ostree. And they've both been doing this for an ungodly amount of time, 20 some years give or take. I don't understand the technical reason for the 1st reboot. The substantial risk for updates is the user environment. If that's killed off even multi-user.target is far less risk to do updates in. But I don't see why system-update.target can't be isolated from graphical.target rather than mandating a reboot to get there. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
