On Wed, Dec 4, 2019 at 5:44 PM John M. Harris Jr <johnmh(a)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 <johnmh(a)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
<fedoradev(a)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.