Fedora 35 To Support Restarting User Services On Package Upgrades

[RahulSundaram]

Oh really? October 5, 2016: https://lwn.net/Articles/702629/

You were saying my memory was faulty or something? I know I'm old, but I'm not quite that old.

Yes really. You are quoting something you haven't understood clearly. Let's look at the original announcement

https://lwn.net/Articles/702648/

"If you're using Workstation, the offline update system is expressly designed to minimize the likelihood of this kind of problem, so please do consider using it. Otherwise, at least run 'dnf update' in a VT - hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it there. Don't do it inside your desktop.

Adam is talking here about something completely really distribution neutral. His recommendation is to run a package manager update outside of a graphical session in a virtual terminal (that does NOT require a reboot) or use an offline update method. Both are these are inherently safer in ANY Linux distribution. There is nothing at all Fedora specific about his recommendations and it has absolutely zero to do with RPM as a packaging format.

[RahulSundaram]

In the "classic model", typically who is charge of packages like libtsl are conscious of its security implication.

This doesn't make it any better. As a Debian user, you must be familiar with this infamous example

https://threatpost.com/how-debian-openssl-bug-almost-spawned-disaster-051809/72669/

It is not specific to Debian btw. Most distribution volunteer packagers don't have the security understanding to do any better than upstream which actually developers the software and often do worse.

[andyprough]

or use an offline update method

Yes, "offline update" was the recommended method. And it involved, among other things, being booted into a special target environment, and then rebooting back into the regular environment. It was a Lennart Poettering thing. I'm not sure if you folks are still offering offline update, I don't keep up with Fedora.

The reason for offline update was: "Replacing libraries and files while the OS is running can cause problems ranging from application crashes to inconsistent system states where processes are using different versions of a library at the same time. By installing system updates 'outside' the normal system operation, we avoid these problems." https://fedoraproject.org/wiki/Featu...eSystemUpdates

I appreciate your love and concern for the reputation of your distro, but no, my memory is not failing me, and I am not plagued by an inability to read and absorb written material. Have a nice day Rahul.

[kreijack]

This doesn't make it any better. As a Debian user, you must be familiar with this infamous example

https://threatpost.com/how-debian-openssl-bug-almost-spawned-disaster-051809/72669/

True, but is this example the exception or the rule ? I am not kidding, really appreciate any significant statistic data (not 1 case) in support of one thesis or the other

It is not specific to Debian btw. Most distribution volunteer packagers don't have the security understanding to do any better than upstream which actually developers the software and often do worse.

The reported one is a good example: who is in position of take a better choice in case of an openssl bug
1) the debian openssl packager (that despite this case has a knowledge above the average of openssl), or
2) the (e.g.) firefox flatpack builder who has to manage also the openssl maintenance ?

[RahulSundaram]

Yes, "offline update" was the recommended method.

It was ONE of the recommended methods. You conveniently omitted the other. Neither represents anything to do with the packaging format

"I am not plagued by an inability to read and absorb written material. "

If your understanding from that post is that this is somehow specific to Fedora or the packaging format, I am afraid you do.

[RahulSundaram]

True, but is this example the exception or the rule ? I am not kidding, really appreciate any significant statistic data (not 1 case) in support of one thesis or the other

Not the exception. Backporting has missed out on the full scope of security fixes even in commercial distros. I am not aware of any specific research done on this but you have to be aware of distros don't represent any kind of nirvana here. I know because I have been involved in distro development directly (although not active recently) before for many many years and still am very familiar with the landscape.

The reported one is a good example: who is in position of take a better choice in case of an openssl bug
1) the debian openssl packager (that despite this case has a knowledge above the average of openssl), or
2) the (e.g.) firefox flatpack builder who has to manage also the openssl maintenance ?

1) Nothing suggests that any specific distro maintainer would have good any security awareness of the packages they maintain. In fact, in the specific example I provided, this is entirely a downstream patch and leaving it alone would have been clearly the better option. Security expertise isn't a qualification for which distro volunteers are vetted for. All you need to know is details on how to package up the software following the guidelines. You don't need to know the codebase at all to do that. If I want something packaged for which some library is a dependency, I have packaged it up for that reason and not because I am a security expert on the library. Upstream on the other hand is always going to be aware of the security details given that they are primarily responsible for it.

2) Typically openssl isn't even bundled by applications in flatpak

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components.bst#L279

It is part of the independently maintained flatpak runtimes and it has staff from multiple companies involved in maintaining it including for security updates and has the additional advantage of sandboxing to mitigate risks. It is merely a question of tradeoffs. Both approaches have advantages and drawbacks. You will have to evaluate it carefully and understand the details throughly. A lot of expressed assumptions here don't stand up to scrutiny.