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

Project Discussion
,
1

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.

4 Likes
2

We add the SUPPORT_END information in /etc/os-release, but I’m not sure what if anything actually makes use of that. It would probably be best if the upstream desktop environment projects added notification options for that instead of us trying to bolt something on downstream.

4 Likes
3

As said in the other comment, this would be great as an idea for the upstream or even preferably, a freedesktop standard of sorts, something that links with the package manager (even if just the GUI ones, but preferably both GUI and CLI) in an interoperable way.

4

Just to have it linked:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQAP5IY4C6QZX7SIJCQFLPKURICXIWJH/

5

100% about that. But I am not sure if there is already something usable existent upstream. @catanzaro indicated in the mailing list that GNOME has already related functions. Also, I don’t know how the Tails people have implemented their solution (they also use GNOME). My experience with GNOME and its development is limited since I don’t use it. How it looks with KDE would be the next question.

6

Fedora (and other Linux distros) should keep nagging the user if using an EOL release. I wouldn’t browse the web with a severely outdated and vulnerable browser.

My suggestion is to keep nagging the user one month before the EOL. And maybe one week before the EOL force trigger the upgrade. Make force upgrade configurable but enabled by default.

I know force upgrading isn’t a popular thing in the Linux community, but that is something that I think Microsoft got right (except for the part where it is almost impossible to disable) since most users are used to have their machines maintain themselves.

There are considerations of course since upgrades could sometimes break a system, so that’s a point against forcing the upgrade.

2 Likes
7

Forced upgrades are a double-edged sword. On one hand, forced upgrades can be good to keep a system secure, but they can also introduce unavoidable breakages. So, to complement your suggestion, forced upgrades could be good for Workstation Edition, but not for Server. Also, ensuring the user has a backup ready could also be important. Say, asking the user if they have a way to backup the system and also a Linux flashdrive ready, and if they do, wait for them to backup important files, and then allow the upgrade

8

One more thing, the update notifier shouldn’t be a GNOME specific thing. Maybe a systemd service that pushes notifications to the currently logged in user(s). Most DEs have support for notifications.

Fedora has already BTRFS by default, a dnf hook that takes a snapshot before the upgrade should be enough to rollback in case of issues.

1 Like
9

Discover (KDE) will notify users of end of life’d distributions that they have to update.

1 Like
10

GNOME Software does display a banner about upgrading, but it’s not super aggressive.

Some users may never open Software, anyway.

1 Like
11

Here’s a little script which should work in any environment which implements the Freedesktop.org Desktop notification spec:

#!/bin/bash

source /etc/os-release

TITLE="It's time to upgrade!"
MESSAGE="$PRETTY_NAME won't get software updates after $SUPPORT_END.\n\n\
This may include critical security fixes. Please upgrade as soon as \
possible! Need help? Folks at $SUPPORT_URL will be glad to assist."


if [[ "$( date +%F )" < $SUPPORT_END ]]; then
    notify-send -u critical -i software-update-urgent "$TITLE" "$MESSAGE"
fi

Bash might be the most elegant approach, but it’s universal.[1] It wouldn’t be hard to extend this using notify-send options to escalate in criticality, and to provide a “remind me in a week” button.

Do all of our desktop spins use systemd user sessions?

  1. in Fedora Linux, at least! ↩︎

2 Likes
12

There is a catch with notify-send, it needs to connect to the user session so it can’t be run as root and notify all users. Using su doesn’t cut it. Maybe there is another way (I suggest loginctl but unsure how exactly to do it).

Edit: I did some research and it could be done using su with some workarounds.
Suggested:

#!/bin/bash
source /etc/os-release

TITLE="It's time to upgrade!"
MESSAGE="$PRETTY_NAME won't get software updates after $SUPPORT_END.\n\n\
This may include critical security fixes. Please upgrade as soon as \
possible! Need help? Folks at $SUPPORT_URL will be glad to assist."


if [[ "$( date +%F )" < $SUPPORT_END ]]; then
    # This will list all logged in users and remove duplicates to avoid multiple notifications for a single user
    for user in $(users | tr ' ' '\n' | sort | uniq | tr '\n' ' '); do
        uid=$(id -u "$user")
        su - $user -c "DISPLAY=\$display DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus \
        notify-send -a 'Fedora Upgrade Notifier' -u critical -i software-update-urgent \"$TITLE\" \"$MESSAGE\""
    done
fi

I tried it and it works for X11 sessions, probably Wayland too.

1 Like
13

I’ve just realized that we disabled F36 package builds as part of the EOL process but did not update the metadata used by Discover to check for EOL’ed distributions so It won’t warn yet. I don’t think that support was available in F36 yet either.

I’ll update the EOL process to add an update to this package as a last step before package upadates are disabled.

1 Like
14

I’ve opened a GNOME Software enhancement request to warn users when their OS has reached EOL. The script proposed above would work too, but we can get a better user experience if we do this via GNOME Software instead.

1 Like