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 Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote:
>
> On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
> > Using the word to be defined in the definition is insufficient and
> > vague. It's meaningless.
> >
> > Feature existence is not support. The community members make a thing
> > supported, and it's only by community effort and prioritization that
> > features are supported. The track record of hibernation support, such
> > as it is, is best effort, but not blocking. If it breaks, Fedora ships
> > with it broken. There are flat out not enough resources to treat it
> > with any higher priority than this - it's not a new issue either.
>
> Nonetheless, it is "supported" in Fedora.

And now you're using private terminology, and it amounts to denialism
and arguing rather than issue progression. It's tedious and makes the
conversation as pointless as talking to a wall.

>Several of the major Spins, for
> example, the KDE Spin, even have a big button for it in the Application
> Launcher widget. We don't need for it to be a blocker for it to be supported.
> There are far too many things Fedora can do for each one to be a blocker.

And likewise there are minimum expectations of reliability for
something to be enabled by default, and hibernation does not qualify.
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/


>
> > The hibernation image is not signed, thus malicious code could be
> > injected into the image, and loaded and executed upon resume. Contrary
> > to you merely saying things as if that makes them true, there is in
> > fact a security issue with hibernation that is incongruent with the
> > purpose of Secure Boot. It would be no different than allowing
> > arbitrary loading of unsigned kernel modules, which is also disallowed
> > by default on Secure Boot systems.
>
> The purpose of Secure Boot is to limit what boots to vendor keys. We've
> circumvented that, but that doesn't make it a "Secure" system.
>
> It makes very little sense to disallow loading of unsigned kernel modules, or
> resuming from an unsigned swap partition, so long as they're encrypted.
> Whoever implemented this, in my opinion, was misguided.

In the first paragraph you correctly state Secure Boot limits what
boots to code that's been signed by Fedora's signing key (or
alternatively user keys, if so configured). And in the second you
describe a means of thwarting Secure Boot by permitting arbitrary code
execution, and advocate for this by default, while also questioning
the decision making capacity of others.

What does encryption have to do with it? Do you think encryption
mimics or is akin to code signing? Does it provide error detection or
error correction? If you change a single block of encrypted data do
you think upon decryption there's EIO or some kind of warning?




>
> > > 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.
> >
> >
> > The thread I cited contains an example of a consistently reproducible
> > unprivileged compile that acts like a fork bomb that will take down
> > the system, including one with swap size = 1x RAM. It reproduces on
> > baremetal and in a VM. The time to OOM providing some chance of
> > recovery is *extended* the bigger swap is. Thus the problem is
> > actually made worse.
>
> That's not a problem. That's the system doing what you've told it. If you
> don't want it to do that, put quotas on that user. This is what we do in
> enterprise environments, for example.

You're making excuses for an unprivileged process fork bombing a
default installation. And you're also changing the goal post by
blaming the user.

The topic, set by you, is the assertion that you've never seen a
system freeze up when swap size is at least 1x RAM. I have provided a
reproducer that contradicts this. And instead of acknowledging that,
either at face value or testing it yourself, you proceed with totally
off topic distractions that also blame the user.

It's a debate style that is intended to generate more debate without
conclusion or progression of the issues, and I consider it
intellectually dishonest.


> > > 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.
> >
> > You asked who told me that it's not supported, I referenced you the
> > thread discussing that point in detail, and yet you're still being
> > dismissive. You have a hypocrisy problem when you accuse others of
> > being dismissive, and yet being dismissive of others is your default
> > position.
>
> That's because it is supported. It works out of box, and several DEs even have
> a button for it. I don't know if GNOME does, but the GNOME Spin has always
> been a bit special.

More private terminology, as if you think repeating it will make it
stick. The difference with my repetition is it's backed by dozens of
conversations among various developers and stakeholders in the Fedora
community considering it not supported, it isn't me personally
asserting a belief or fantasy.

It doesn't work out of the box with sufficient consistency or
predictability to consider it supported or supportable. You'll find
myriad upstream and downstream bug reports about hibernation that
languish indefinitely. Some do get fixed. Whether it works depends on
make/model, the firmware revision, and kernel version.

A common theme in the discussion thread I cite earlier in this email,
is corrupt hibernation images on resume. I have two computers that
exhibit this behavior. I do not consider that it works out of the box
at all. If I take a very selfish point of view about only my
experiences I would say it's 100% broken out of the box.

But being one to recognize the lay of the land is complex, I don't
take only my own experiences to be the  way of things, like you are.
I'm not dismissive of other people's experiences, as you are. I use an
inclusive language: it works for some, it doesn't work for others.
It's sufficiently unreliable and unpredictable that it cannot
reasonably be considered supported or supportable on Fedora without
either a lot more resources, or a white list of hardware.

Your style of debate is grating and can be summarized as: 'I am always
right and you are always wrong, you should do things my way because
you are doing it wrong and everyone doing things differently than I
want them is wrong and misguided.'

It's annoying.

>
> The only time it wouldn't work seems to be in one of those special UEFI +
> Secure Boot cases.

It's not special. It happens to be the default firmware and
configuration of most new x86_64 hardware, and the default policy upon
installation by Fedora. And that means hibernation is not presently
possible by default on those systems. There is no agreement by
distributions how to handle hibernation image signing that upstream
will accept and Fedora isn't likely to carry out of tree patches for
such a thing.


-- 
Chris Murphy
_______________________________________________
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