Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote:
> On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx>
> wrote:
> >
> >
> > On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
> > 
> > > Hibernation is out of scope to rely on, let alone make a default, for
> > > at least the following reasons:
> > > a. It's not sufficiently well supported upstream for regressions that
> > > may appear in new kernels, and not supported by the Fedora kernel
> > > team.
> >
> >
> >
> > I'm not sure who told you this, but that's not the case. Hibernation is
> > supported in Fedora.
> 
> 
> No it isn't. But as I've asked you for your definition of "support"
> and you still haven't, and I've offered my own and you haven't
> disputed it, I win. That's the short version because you have a track
> record of not reading provided references. For the long version:

There's nothing to "win". This isn't a competition. We're all on the same side 
here.

My definition of "supported in Fedora" is.. supported in Fedora. You can do it 
in Fedora. Without modifying anything. In my DE, for example, I'd do that by 
pressing Alt + F1, the Super key, or click the KDE icon in the left of my 
primary screen's Panel, Leave -> Hibernate.

> > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
> >
> >
> >
> > How so? What "kernel lockdown" are you referring to?
> 
> 
> [    1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
> kernel_lockdown.7
> 
> And also the above kernel list email thread mentions it also. I'm
> surprised you haven't heard of it, it's been around for quite a long
> time as it's an obvious attack vector that obviates the point of
> Secure Boot.

I don't have a personal system that uses UEFI, much less "Secure Boot", so I 
things that affect those systems in Fedora, but not the versions of RHEL I 
work with, I have no reason to follow normally. I'll take a look, however. 
"Secure Boot" is a misnomer, by the way, and hibernation is not a security 
issue. Suspension is, but not hibernation.

> > What are you talking about? You should have at least 1x RAM for swap
> > whether you use hibernation or not. If you're having issues, you can
> > adjust the swappiness as needed. There is no "effective loss of the
> > system" involved.
...snip...
> In the case where swap is used heavily, rather than incidentally, the
> UX is atrocious. The resulting swap thrashing is ai bad the system is
> functionally lost and it's completely reasonable for a user to force
> power off.

What are you suggesting the UX is atrocious for? Modifying the swappiness 
value? I have come across situations where a system without swap OOMs, and 
effectively freezes up as a result, causing the user to hard-boot the system, 
but I have never seen that with a system where swap was at least 1x the amount 
of RAM.

> > > d. There's no release criterion. Therefore the project wouldn't block
> > > release on any discovered bugs. Serious bugs would likely lead to
> > > reverting any use of hibernation by default, and so it's not at all
> > > likely it'll become supported by default.
> >
> >
> >
> > Blockers are dynamic. We can make new blockers if we need them.
> 
> 
> There's actual background study and work to be done before a release
> criterion is accepted. Saying things doesn't make them true. The
> criterion itself needs to be written, test cases produced and sanity
> checked, and perhaps most importantly: who will be fixing the blocker
> bugs? You need willing people to be available from multiple teams,
> each having enough resources to ensure it gets highly escalated fixes.

It doesn't really make any sense to dismiss this. If it's deemed necessary for 
there to be a blocker, we can make a new blocker. That's a non-issue.

-- 
John M. Harris, Jr.
Splentity

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux