On Wednesday, December 4, 2019 6:08:31 PM MST Chris Murphy wrote: > On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr <joh...@splentity.com> > wrote: > > > > > > On Wednesday, December 4, 2019 5:41:13 PM MST Chris Murphy wrote: > > > > > On Wed, Dec 4, 2019 at 5:14 PM John M. Harris Jr <joh...@splentity.com> > > > wrote: > > > > > > > > > > > > > > > > > > > On Wednesday, December 4, 2019 5:09:55 PM MST Chris Murphy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 4, 2019 at 4:41 PM Marius Schwarz > > > > > <fedora...@cloud-foo.de> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 04.12.19 um 02:02 schrieb Chris Murphy: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anaconda custom partitioning has a per mount point encryption > > > > > > > option. > > > > > > > I can LUKS encrypt only the volume mounted at /home. And if I > > > > > > > do > > > > > > > this, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do this, someone can manipulate your system to trojan > > > > > > horse > > > > > > your > > > > > > passwords, > > > > > > when he has physical access to it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Full-Diskencryption ( /boot included ) is the only way to protect > > > > > > the > > > > > > system itself. > > > > > > Anything else is simply not secure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > systemd-homed doesn't depend on /etc/passwd or /etc/shadow for > > > > > authentication. By all means its security guarantees should be > > > > > evaluated. > > > > > https://github.com/systemd/systemd/pull/14096 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What you're talking about is entirely up to the user to configure > > > > > manually. Fedora installations today don't support bootloader lock > > > > > down, encrypted /boot, or purging the LUKS key from memory during > > > > > suspend, out of the box. And therefore I'm not sure what your goal > > > > > posts are, what two things you're comparing. > > > > > > > > > > > > > > > > > > > > > > > > It may be the case that the GNOME Spin doesn't support that, but it > > > > is > > > > supported with the KDE Spin. I don't think it's likely that anything > > > > in > > > > the GNOME image would break that, but it's possible I suppose. > > > > > > > > > > > > > > > I have no idea what you mean by "supported" nor which of the multiple > > > characteristics I listed you think apply to Fedora KDE. > > > > > > > > > > > > What I mean by support = that which Fedora produces in release > > > blocking desktops, most typically in a default configuration, and for > > > which release criteria have been written. None of the things I wrote > > > apply to Fedora KDE either, so it's simply not correct to call them > > > supported. The functionality may exist in KDE, but that's not the same > > > thing as what Fedora supports. And I did very clearly write "Fedora > > > installations today don't support..." > > > > > > > > Fedora supports installation on ARM devices with vboot today. > > > The only Fedora KDE image that's release blocking is x86_64. > https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
What does this have to do with "Fedora installations today don't support..."? -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
