Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

[Christopher Klooz]

The below is a duplicate from discourse (I suggest to focus the 
discussion there): 
https://discussion.fedoraproject.org/t/potential-security-issue-for-begin...



I just became aware of another topic from a user who elaborates their 
problem and “by the way” mentions to use Fedora 35. The user provides 
this information in order to give an overview of his system 
configuration and thus does not consider this as part of the problem.

I have seen many of these topics over time, and I guess there are many 
more users out there who use obsoleted Fedora releases (the less 
experienced they are, the more they are likely to end up with obsoleted 
releases, and the less likely they are to end up on ask.fedora so that 
we can make them aware).

We officially want to make Fedora usable for average users (or 
beginners), but many (if not most) average users deploy their systems in 
a “fire and forget” manner: once they made it work, they maybe enable 
updates and such and then they no longer care if everything *seems* to 
work fine.

I assume that many of these users are not aware that they no longer 
receive updates, which can be dangerous.

First of all, I don’t use my Fedora installations until their /end of 
life/, so I don’t know if we have any means in place that shall make 
users aware once their release reaches /end of life/?

*If not*, does it make sense to add some means?

If we promote Fedora for average users/beginners, we have to also 
consider their behavior.

On one hand, it would be cool to make them a month or two before /end of 
life/ aware with a warning message that automatically forwards them to 
the GUI upgrade with a click and also allows them to click “warn me 
again tomorrow” or such.

On the other hand, more easy to implement solutions like that of Tails 
could be sufficient solutions, too: once the Tails ISO image is started 
(live system) and online, it checks if there are new images available. 
If so, it opens a warning window that makes the user aware that this 
image should no longer be used and shows a link and a short elaboration 
of how to get the new one.

Of course there are alternatives, too. Even an apparent bullet point on 
getfedora.org <http://getfedora.org> would be a good first step (we 
could link it to Fedora being always up to date with most modern 
technologies, to link it to something positive). In either case, I think 
a short discussion of this makes sense.

This also applies to all Spins.


Best,
Chris

[Chris Kelley]

You can lead a horse to water but you can't make it drink:
https://fedoraproject.org/workstation/

Each version is updated for approximately 13 months, and upgrades between
>  versions are quick and easy
>  
It's right next to the download button :-) Likewise here:
https://docs.fedoraproject.org/en-US/project/#_first

Users are gonna user, if someone wants to not read any of the docs about
what Fedora is, hit that button and put F38 on a machine and run it for 10
years they will. We can only be very clear about what is in support and
what is not, and I think the people responsible for that do a great job.
For what it's worth, I know there are Fedora devs out there running EOL
versions of Fedora, so it is not just new users doing this. Not everyone
has the same "upgrade first; ask questions later" attitude to OS updates I
have it would seem ;-)

I seem to recall a thread from a few months back discussing how a machine
can work out for itself whether it is EOL (or about to be) but I can't seem
to find it. Hopefully someone will be able to elaborate on that part of
your discussion because that reminder would be helpful.

Cheers,

Chris

On Fri, 11 Aug 2023 at 15:25, Christopher Klooz <py0xc3(a)posteo.net&gt; wrote:

>  The below is a duplicate from discourse (I suggest to focus the
> discussion
>  there):
>
> https://discussion.fedoraproject.org/t/potential-security-issue-for-begin...
>
>  I just became aware of another topic from a user who elaborates their
>  problem and “by the way” mentions to use Fedora 35. The user provides this
>  information in order to give an overview of his system configuration and
>  thus does not consider this as part of the problem.
>
>  I have seen many of these topics over time, and I guess there are many
>  more users out there who use obsoleted Fedora releases (the less
>  experienced they are, the more they are likely to end up with obsoleted
>  releases, and the less likely they are to end up on ask.fedora so that we
>  can make them aware).
>
>  We officially want to make Fedora usable for average users (or beginners),
>  but many (if not most) average users deploy their systems in a “fire and
>  forget” manner: once they made it work, they maybe enable updates and such
>  and then they no longer care if everything *seems* to work fine.
>
>  I assume that many of these users are not aware that they no longer
>  receive updates, which can be dangerous.
>
>  First of all, I don’t use my Fedora installations until their *end of
>  life*, so I don’t know if we have any means in place that shall make
>  users aware once their release reaches *end of life*?
>
>  *If not*, does it make sense to add some means?
>
>  If we promote Fedora for average users/beginners, we have to also consider
>  their behavior.
>
>  On one hand, it would be cool to make them a month or two before *end of
>  life* aware with a warning message that automatically forwards them to
>  the GUI upgrade with a click and also allows them to click “warn me again
>  tomorrow” or such.
>
>  On the other hand, more easy to implement solutions like that of Tails
>  could be sufficient solutions, too: once the Tails ISO image is started
>  (live system) and online, it checks if there are new images available. If
>  so, it opens a warning window that makes the user aware that this image
>  should no longer be used and shows a link and a short elaboration of how to
>  get the new one.
>
>  Of course there are alternatives, too. Even an apparent bullet point on
>  getfedora.org would be a good first step (we could link it to Fedora
>  being always up to date with most modern technologies, to link it to
>  something positive). In either case, I think a short discussion of this
>  makes sense.
>
>  This also applies to all Spins.
>
>  Best,
>  Chris
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Michael Catanzaro]

On Fri, Aug 11 2023 at 02:24:22 PM +0000, Christopher Klooz 
<py0xc3(a)posteo.net&gt; wrote:
>  First of all, I don’t use my Fedora installations until their end 
>  of life, so I don’t know if we have any means in place that shall 
>  make users aware once their release reaches end of life? 
Fedora Workstation will display a nag notification once per week when a 
newer release is available, so unless you uninstall GNOME Software or 
ignore all notifications, you should at least be aware that a newer 
version is available.

I had thought we had daily nag notifications once the release has 
reached end of life, but maybe I was imagining it because I can't find 
any evidence that this actually exists. I think GNOME Software should 
look at SUPPORT_END in /etc/os-release and nag more frequently.

Highly recommend other Fedora editions consider similar notifications.

Michael

[Leon Fauster]

Am 11.08.23 um 17:59 schrieb Michael Catanzaro:
>  On Fri, Aug 11 2023 at 02:24:22 PM +0000, Christopher Klooz 
>  <py0xc3(a)posteo.net&gt; wrote:
> > First of all, I don’t use my Fedora installations until their end of 
> > life, so I don’t know if we have any means in place that shall make 
> > users aware once their release reaches end of life?
>  
>  Fedora Workstation will display a nag notification once per week when a 
>  newer release is available, so unless you uninstall GNOME Software or 
>  ignore all notifications, you should at least be aware that a newer 
>  version is available.
>  
>  I had thought we had daily nag notifications once the release has 
>  reached end of life, but maybe I was imagining it because I can't find 
>  any evidence that this actually exists. I think GNOME Software should 
>  look at SUPPORT_END in /etc/os-release and nag more frequently.
>   
Please do not clutter the user experience with such _additional_
informations. The user on such workstations are not always the
administrator and such informations would not help/change the
situation either. I actually do a lot of config work to disable
such UI "features". For my case the user does not even understands
or notice it when a major upgrade was done (albeit some UI improvments).
Of course the active usage of Gnome software or dnf could and should
provide such information in a prominent way ...

-- 
Leon

[Matthew Garrett]

On Sat, Aug 12, 2023 at 12:07:05PM +0200, Leon Fauster via devel wrote:

>  Please do not clutter the user experience with such _additional_
>  informations. The user on such workstations are not always the
>  administrator and such informations would not help/change the
>  situation either. I actually do a lot of config work to disable
>  such UI "features". For my case the user does not even understands
>  or notice it when a major upgrade was done (albeit some UI improvments).
>  Of course the active usage of Gnome software or dnf could and should
>  provide such information in a prominent way ... 
I think it's reasonable that this should be something under admin 
control, but for the common default scenario where the single uesr is 
also the admin it seems reasonable to let the user know that they'll no 
longer receive security updates?

[Björn Persson]

Matthew Garrett wrote:
>  On Sat, Aug 12, 2023 at 12:07:05PM +0200, Leon Fauster via devel
> wrote:
>  > Please do not clutter the user experience with such _additional_
>  > informations. The user on such workstations are not always the
>  > administrator and such informations would not help/change the
>  > situation either.
>  
>  I think it's reasonable that this should be something under admin 
>  control, but for the common default scenario where the single uesr is 
>  also the admin it seems reasonable to let the user know that they'll no 
>  longer receive security updates? 
Notifying the user only if they're a member of the wheel group seems
like a reasonable default.

Björn Persson

[Kevin Kofler]

Michael Catanzaro wrote:
>  Fedora Workstation will display a nag notification once per week when
> a
>  newer release is available, so unless you uninstall GNOME Software or
>  ignore all notifications, you should at least be aware that a newer
>  version is available.
>  
>  I had thought we had daily nag notifications once the release has
>  reached end of life, but maybe I was imagining it because I can't find
>  any evidence that this actually exists. I think GNOME Software should
>  look at SUPPORT_END in /etc/os-release and nag more frequently.
>  
>  Highly recommend other Fedora editions consider similar notifications. 
I don't think more nagging is going to help. It is just going to be 
considered yet another annoying nag to ignore or click away. Like it or not, 
non-technical users are NEVER going to upgrade to a new operating system 
release. Not now, not 10 years from now. Until their computer physically 
breaks down, at least. There is just nothing you can do about it.

        Kevin Kofler

[Przemek Klosowski]

On 8/13/23 16:57, Kevin Kofler via devel wrote:
> > look at SUPPORT_END in /etc/os-release and nag more frequently.
> >
> > Highly recommend other Fedora editions consider similar notifications.
>  I don't think more nagging is going to help. It is just going to be
>  considered yet another annoying nag to ignore or click away. Like it or not,
>  non-technical users are NEVER going to upgrade to a new operating system
>  release. Not now, not 10 years from now. Until their computer physically
>  breaks down, at least. There is just nothing you can do about it. 
I believe this is overly pessimistic: people tend to upgrade their 
Android and iOS devices and applications, because the update process is 
low-friction and well tested so that people tend to trust it.

I have personally had multiple Fedora upgrade issues due to lack of 
space in the root filesystem, so maybe Fedora is not yet at a point 
where we can unconditionally launch into upgrading, but it's a technical 
issue that can be corrected.

We already have SUPPORT_END so I think it makes sense to use it.

[Stephen Smoogen]

On Mon, 14 Aug 2023 at 17:59, Przemek Klosowski via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 8/13/23 16:57, Kevin Kofler via devel wrote:
>
>  look at SUPPORT_END in /etc/os-release and nag more frequently.
>
>  Highly recommend other Fedora editions consider similar notifications.
>
>  I don't think more nagging is going to help. It is just going to be
>  considered yet another annoying nag to ignore or click away. Like it or not,
>  non-technical users are NEVER going to upgrade to a new operating system
>  release. Not now, not 10 years from now. Until their computer physically
>  breaks down, at least. There is just nothing you can do about it.
>
>  I believe this is overly pessimistic: people tend to upgrade their Android
>  and iOS devices and applications, because the update process is
>  low-friction and well tested so that people tend to trust it.
>
>  
It is fairly well tested because the entire phone hardware set is a
'known'
quantity. There are also several different layers of 'testing' and quality
control which happen:
0. The OS manufacturer
1. The phone manufacturer (for android about 2 years, for iphone for 10)
2. The wireless carrier (for android about 3 years, for iphone for 7)
3. Sometimes major software app manufacturers

Each of these groups have 'farms' of several hundred of each type of phone
which get continual updates and they have a long certification process to
make sure that they reach 'all the phones updated without problems and ran
N hours without issues afterwards'. This is part of the reason it can take
months for a release from The OS manufacturer (aka Android) to get pushed
out to fleets of phones. It is fairly 'expensive' work with lots of little
issues having to be tracked down and passed. [Because even when you 'built
the phone' you find out that N% of that batch still acts slightly different
from the rest on this update.]

In the desktop/computer mode this is just outside of anything that I think
a volunteer oriented organization could try to make work at scale.

>  I have personally had multiple Fedora upgrade issues due to lack of
> space
>  in the root filesystem, so maybe Fedora is not yet at a point where we can
>  unconditionally launch into upgrading, but it's a technical issue that can
>  be corrected.
>
>  We already have SUPPORT_END so I think it makes sense to use it.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Przemek Klosowski]

On 8/15/23 09:51, Stephen Smoogen wrote:
>  Each of these groups have 'farms' of several hundred of each
> type of 
>  phone which get continual updates and they have a long certification 
>  process to make sure that they reach 'all the phones updated without 
>  problems and ran N hours without issues afterwards'. This is part of 
>  the reason it can take months for a release from The OS manufacturer 
>  (aka Android) to get pushed out to fleets of phones. It is fairly 
>  'expensive' work with lots of little issues having to be tracked down 
>  and passed. [Because even when you 'built the phone' you find out that 
>  N% of that batch still acts slightly different from the rest on this 
>  update.]
>
>  In the desktop/computer mode this is just outside of anything that I 
>  think a volunteer oriented organization could try to make work at scale. 
I do see
your point that there's too much variability in the hardware 
and software setup to be able to exhaustively test all the upgrade 
paths, but Adam W. and his group do such excellent job of testing that I 
think statistically a failed update is a black swan. It would be nice to 
know the actual failure numbers, but we'd need some telemetry for that 
:).  Maybe the technical challenge that would solve this is rollback of 
failed updates. OStree arguably has an advantage here over file-based 
updates.

For what it's worth I personally was blessed with simple upgrade 
problems, fixed by temporarily deleting a bunch of large packages like 
KiCAD 3D models RPM, etc.  I was always able to upgrade, so my anecdata 
makes me trust Fedora updates. In fact, the main challenge I encountered 
is the accidental persistence of various 'experimental' UI and OS 
settings I did over time that result in a behavior different from a 
fresh install---I sometimes wish there was an interactive, granular 
'restore factory defaults' option that would let me keep some settings 
and revert others.