Flatpaks for Fedora 27

Posted Jul 27, 2017 11:31 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Flatpaks for Fedora 27 by mjthayer
Parent article: Flatpaks for Fedora 27

Secure Boot systems will reject any unsigned kernel modules, so you're left either asking users to disable a security feature or manage signing themselves (the easiest way being to keep the private key material on the local system, which isn't a huge improvement over disabling it). In addition, there's a risk that kernel security updates will break your modules, so users still end up being trained to do things that reduce their security. The support load for all of this ends up on distributions, so it's not really surprising that they wouldn't place handling out of tree kernel modules as a high priority - if a Virtualbox Flatpak fails to work on Fedora but works on Ubuntu, it's still the Fedora developers who are going to be blamed even if all they did was move to a new kernel version more quickly.

In the absence of a way to ensure that out of tree kernel modules can be built on all distributions, it'd be misleading to support them in a project that's intended to make it possible to produce packages that can be used on all distributions.

Flatpaks for Fedora 27

Posted Jul 28, 2017 10:08 UTC (Fri) by mjthayer (guest, #39183) [Link] (2 responses)

If the Flatpak is provided by Fedora, then yes, users might blame Fedora if a security update temporarily stopped it from working. If it comes from us, I would more expect them to blame us, but perhaps I am being naive here. I can't really see myself pointing the finger at Fedora in this case if users come to us (I have pointed the finger at others in the past, but only when I was sufficiently convinced that it was justified).

My current thought is that some sort of user self-signing would be the best route, trying to make it as easy as possible for the user to choose a trade-off between security and ease of use - say store the key on the local disk, store it on a USB key, or make it as clear as possible how the user can do it themself in the way that suits them best. By the way, thank you for drawing my attention to this. It wasn't really on my radar, though a couple of colleagues had started looking at it.

Regarding Flatpak, not only do we install kernel modules, we also install system services. That is also something which Flatpak would probably not cope with, so if we were to go the Flatpak route we would probably want a second component installed outside of Flatpak which it could talk to. Any thoughts from the Flatpak developers welcome here.

Flatpaks for Fedora 27

Posted Jul 28, 2017 13:34 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

You're definitely being naïve here. Microsoft's experience with Windows was that 85% of Windows XP blue screen crashes could be definitively traced to buggy third party code; 30% of Windows Vista crashes traced to a single vendor's device drivers. And yet, who got the blame for Windows being crashy? The device makers? No, Microsoft.

The same sort of thing will happen if a Fedora upgrade breaks your installed software - the last thing you did was update Fedora, and now VirtualBox fails. Here, not only is it obvious that things have stopped working, but the proximate cause is obvious - "I updated Fedora and now my apps don't work!" - and thus Fedora gets the blame and has to shunt things onto you.

Flatpaks for Fedora 27

Posted Jul 28, 2017 14:53 UTC (Fri) by mjthayer (guest, #39183) [Link]

Your conclusion may still be right, but I don't think that the example is quite comparable. A comparable situation to a blue screen on Windows would be a kernel panic in Fedora, which is a far cry from VirtualBox refusing to start with a message about driver not loaded. Particularly as VirtualBox is third-party software in an environment where third-party is a second-class citizen, so to speak, and automatically treated as less reliable, particularly in regard to system integration. (Not that integration is any harder than on Windows or OS X, where we do not have the second-class status - if anything it is the other way round.)

My version of your blue screen example would be when VirtualBox multi-monitor full-screen handling was not working on Ubuntu. It was a simple mistake in the Unity code, a function being called with (x1, y1, x2, y2) instead of (x, y, w, h) or vice versa, and no one else used that particular EWMH functionality, so it was our risk so to speak. So users reasonably assumed it was our bug, and as a result I spent quite a lot of time getting a one-line fix into Unity. Whatever, on a closed operating system we would have had to live with it.