To be absolutely clear, this is unacceptable because it makes it look like Fedora is not trustworthy.

The counterargument is that distributing desktop applications in RPM format is unsafe because if the app is compromised, it has unlimited permission to do whatever the attacker wants with your data. Only sandboxed applications should be displayed as trustworthy. I think the change makes sense, and the problem is it happened upstream sooner than Fedora expected, when we're still shipping RPMs. :/

I agree the UI is not good, though. It says the app's permissions are unknown, but that is false. They are very well-known. It has unlimited permission to do whatever it wants (to the extent allowed by your user's Unix permissions).

The counterargument is that distributing desktop applications in RPM format is unsafe because if the app is compromised, it has unlimited permission to do whatever the attacker wants with your data. Only sandboxed applications should be displayed as trustworthy. I think the change makes sense, and the problem is it happened upstream sooner than Fedora expected, when we're still shipping RPMs. :/

Not a valid argument for content sources we declare as trusted. And it will cause problems from a publicity point of view. This is a crap argument. Our own content should never be called unsafe like this.

It might be a good idea to consider an application that really is clearly unsafe to use, like evince. Poppler is full of remote code execution bugs (all C or C++ software is, because every memory management bug is a remote code execution bug). It is completely unsandboxed, so the slightest memory management mistake is all it takes to compromise the user. Our evince is extremely unsafe. And there are no plans to fix this by sandboxing the RPM version of poppler. The only plausible solution is to flatpak it so that it benefits from the flatpak sandbox.

Now consider Totem. Take the paragraph above, replace "poppler" with "GStreamer" and we have the same argument. In fact, we know for certain that Totem was recently exploited to achieve remote code execution. In fairness, this particular attack wouldn't have been prevented by the Flatpak sandbox because Totem requires network permission and in this case the goal was just to get the user's IP address, but the flatpak sandbox would have mitigated a more normal attack.

IMO RPM-based applications are unsafe if they (a) open files or connect to the network, and (b) do not implement their own sandbox. (b) is an escape hatch that really covers web browsers only, because I don't know of any other desktop applications doing this.

If something that isn't sandboxed is unsafe then every package that is an RPM, DEB, etc is classified as "unsafe".

Calling something as "Unsafe" just because it is unknown does not make something unsafe either. If software is included in default repos there is no reason to expect the software to be "unsafe".

If GNOME wants to label stuff as "not curated", "not sandboxed" or something like that then alright that's fine but calling it "unsafe" will just scare people from using most applications.

Seems like upstream changed this recently https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/937

I don't know why someone thought it'd be a good idea to use the words "safe" or "unsafe" at all. That invokes a whole different imagery and often leads to making users unnecessarily fearful of their system.

IMO RPM-based applications are unsafe if they (a) open files or connect to the network, and (b) do not implement their own sandbox. (b) is an escape hatch that really covers web browsers only, because I don't know of any other desktop applications doing this.

We've always known that sandboxing is orthogonal to the delivery mechanism. However, it's up to the GNOME desktop to actually default to sandboxing applications being run if they want to. It's not like the tools that are used for the Flatpak sandbox are exclusive to Flatpak, after all.

something that shocked me was that

To be absolutely clear, this is unacceptable

This is a crap argument.

I don't know why someone thought it'd be a good idea

I'd appreciate it if we could cool this ticket down, and lose the accusatory language. All it does is create an unpleasant environment.

something that shocked me was that

To be absolutely clear, this is unacceptable

This is a crap argument.

I don't know why someone thought it'd be a good idea

I'd appreciate it if we could cool this ticket down, and lose the accusatory language. All it does is create an unpleasant environment.

Since we're quoting me about this, and I'm the upset user who has discovered that everything I ship in Fedora is being marked as unsafe, I think I have some right to be extremely unhappy about this. GNOME Software is basically telling everyone that all the stuff Fedora offers is bad.

I think we can have this conversation without accusatory language but simulatenously recognize that this can be legitimately upsetting. Calling packages "unsafe" is also strong language -- and it's a little unfair to call out someone saying that they're shocked to see something as accusatory language. It's valid to have that reaction. Let's see what we can do constructively to make things better.

I think my concern here would be a lot greater if the metric here were "mark all flatpaks safe, mark all rpms unsafe", but that's not what I'm seeing. In fact, the Thunderbird Flatpak from both Flathub and Fedora Flatpaks are flat-out red "Unsafe" rather than just yellow-warning "Potentially Unsafe".

Is there a term we could use other than "safe"? There are a, lot of other aspects that "safety" might entail, and fundamentally I don't think telling users that all software is "potentially unsafe" is really helpful. I mean, maybe it is, but what are users supposed to do about it?

Perhaps one thing we could do is: if there is a single characteristic which makes an app go from green to yellow (or red), show that characteristic at the top level? That way, it'd show up as the specific "Unknown Permissions" rather than the general.

It also was not obvious to me that the tile could be clicked for more information. Maybe that could be more clear?

On the plus side, I really think this UI is a huge improvement in showing the advantages of open source / free software clearly.

Saying that you are shocked is fine, but saying "I don't know why someone thought it'd be a good idea" to me is crossing the line to ad-hominen, unconstructive language. GNOME Software isn't designed and coded by "someone" - it's designed and coded by particular human beings we need to work with make improvements (Philip, Milan, Allan, etc.)

I can't speak fully to the motivations behind this change, or alternatives that were considered, but there's long been a question of how do we encourage Flatpak creators to lock down their permissions - without making it impossible to create Flatpaks of legacy applications that can't be effectively sandboxed. Giving a clear carrot to Flatpak creators and application authors to take advantage of Flatpak sandboxing is why someone thought it was a good idea!

Maybe, for practical reasons, we need to not show the safety category for RPM applications. I was going to say that we exempt them from the "unknown permissions" to "potentially unsafe" rollup, but I think labelling an RPM as "safe" and the equivalently sandboxed Flatpak as "potentially unsafe" is definitely deceptive.

Yes, to be clear, I understand the emotion but I don't think it's excuse for attacks or for phrases like "this is a crap argument" : Neal, everyone -- please assume good intentions and treat people that way. We all want to deliver software to our users in the best way possible, and inform them in a way that helps users understand the choices they are making.

On a pragmatic level, to @catanzaro's point from many comments back, it does seem like "Not sandboxed" would be a lot more informative than "Unknown permissions" when in fact the fundamental concern is that there aren't any permissions to give.

I think part of the problem comes down to trying to roll up a lot of different things into one top-level value. @otaylor I see your point about sandboxing, but there are other axes of security which don't seem to cause the top-level ding. I notice that RPMs and Flatpaks from the Fedora repositories get App Comes From a Trusted Source in green in the details (which is great!) but lack of that doesn't get given as a negative for packages coming from Flathub. Maybe an answer at least for now is to make Sandboxed a "green" item in this way, but do not default to warning on its lack just yet?

On a pragmatic level, to @catanzaro's point from many comments back, it does seem like "Not sandboxed" would be a lot more informative than "Unknown permissions" when in fact the fundamental concern is that there aren't any permissions to give.

Honestly I think I prefer "unsafe" since many users don't understand how essential the sandbox is. I kinda get the impression that Neal thinks it is safe to run unsandboxed desktop software packaged as Fedora RPMs. It is very much not safe, not at all, at least not for a program that open files or accesses the network. I understand that presenting all our software as unsafe in GNOME Software is a user experience issue, but it's also true, and that's something we need to think real hard about.

Anyway, "not sandboxed" is technical jargon that few users will understand. Even experienced users may not understand the importance of limiting application permissions via a sandbox.

So the current language is "potentially unsafe" which is almost not strong enough. An unsandboxed application is almost certainly unsafe because it is unusual for an application to neither open files nor access the network.

On a pragmatic level, to @catanzaro's point from many comments back, it does seem like "Not sandboxed" would be a lot more informative than "Unknown permissions" when in fact the fundamental concern is that there aren't any permissions to give.

Honestly I think I prefer "unsafe" since many users don't understand how essential the sandbox is. I kinda get the impression that Neal thinks it is safe to run unsandboxed desktop software packaged as Fedora RPMs. It is very much not safe, not at all, at least not for a program that open files or accesses the network. I understand that presenting all our software as unsafe in GNOME Software is a user experience issue, but it's also true, and that's something we need to think real hard about.

If it is truly necessary, then you should decouple the sandbox from the delivery format and make it something GNOME and others can enforce on applications through permission metadata. There is plenty of prior art for sandboxing arbitrary applications (SELinux, Firejail, etc.). What GNOME Software is doing now is not only unproductive, it is actively harmful.

You actually do have a lot of knobs to be able to sandbox arbitrary applications (systemd-run, Firejail, SELinux sandbox, Bubblewrap, etc.). Pick a strategy and do it.

If it is truly necessary, then you should decouple the sandbox from the delivery format and make it something GNOME and others can enforce on applications through permission metadata. There is plenty of prior art for sandboxing arbitrary applications (SELinux, Firejail, etc.). What GNOME Software is doing now is not only unproductive, it is actively harmful.

I think if someone came up with an way to run an RPM-packaged application with filesystem access sandboxed, with D-Bus filtering, using xdg-portals or equivalent mechanisms to access user resources, and so forth, and a way to express "this application is run sandboxed" in DNF metadata, it would be absolutely reasonable to look at supporting that within GNOME Software.

But creating that mechanism can't be thrown up as a prerequisite for GNOME Software to highlight the increased security of locking down applications with Flatpak.

If it is truly necessary, then you should decouple the sandbox from the delivery format and make it something GNOME and others can enforce on applications through permission metadata. There is plenty of prior art for sandboxing arbitrary applications (SELinux, Firejail, etc.). What GNOME Software is doing now is not only unproductive, it is actively harmful.

I think if someone came up with an way to run an RPM-packaged application with filesystem access sandboxed, with D-Bus filtering, using xdg-portals or equivalent mechanisms to access user resources, and so forth, and a way to express "this application is run sandboxed" in DNF metadata, it would be absolutely reasonable to look at supporting that within GNOME Software.

It's already been done before. Firejail itself does this, and there are a bundle of profiles for Firejail that can be applied to regular applications to sandbox them. For something more scalable, we're just missing a way to define the metadata for application packages to ship for it to auto-activate.

But creating that mechanism can't be thrown up as a prerequisite for GNOME Software to highlight the increased security of locking down applications with Flatpak.

Yes, it absolutely can. Because there's more than one dimension of trust, and GNOME Software is attempting to violate the trust we convey with our distribution. If you want to highlight increased security of Flatpaks with "safe" permissions defined, fine. But highlighting the absence of that in trusted RPM content as "unsafe" is not acceptable, because it implies that the distribution cannot be trusted to provide content worth using.

I cannot emphasize enough how much of a problem it is that GNOME Software calls our own packages "unsafe".

Put another way: imagine how much of a problem this would be if it slipped into Red Hat Enterprise Linux. Software in the distribution calling its own packages "unsafe" would be a major problem because it conflicts with a major tenant of RHEL marketing: that the distribution itself is tested and validated for quality, security, and reliability.

I repeat: this is not okay to leave as-is in Fedora.

Honestly I think I prefer "unsafe" since many users don't understand how essential the sandbox is

Well, except, that's not actually what's being presented. It says "unsafe", but for explanation only offers "Software has unknown permissions" -- as you pointed out. That doesn't help people understand how essential sandboxing is.

But creating that mechanism can't be thrown up as a prerequisite for GNOME Software to highlight the increased security of locking down applications with Flatpak.

But GNOME Software in this design has the ability to highlight increased security without lack of that highlight being taken into consideration, right? Instead of making the unknown permissions yellow flag (which is unclear anyway), make having it a green flag, just like "app comes from a trusted source"?

I don't think this is great experience for users, because we don't have any alternatives to offer them right now. And there's the "security warning fatigue" issue -- I don't think we should teach people that the whole thing is to be ignored.

I do think we should offer more secure alternatives, but I think introducing requirements for highlighting it in a strong user facing way needs more communication with app maintainers and packagers and clear, phased-in plan. When we can, I'm all for building Flatpaks from Fedora which have all of the green boxes lit up, and none of the red or yellow.

Saying that you are shocked is fine, but saying "I don't know why someone thought it'd be a good idea" to me is crossing the line to ad-hominen, unconstructive language. GNOME Software isn't designed and coded by "someone" - it's designed and coded by particular human beings we need to work with make improvements (Philip, Milan, Allan, etc.)

I'm sorry for the comments which can be read as personal attacks. I didn't mean it that way. I am just extremely upset and feel like all the work I do in Fedora is being attacked by stuff like this. I know that y'all mean well and are trying to do right for both users and for Fedora. This may be a well-meaning change from the GNOME side, but I feel like they missed the plot here, and I would like to find a way to fix this before Fedora Linux 35 is released.

To be clear, nobody was approaching this from the upstream side with the thought "let's label all non-Flatpak applications as potentially unsafe". GNOME Software is used in different places, and has a complex system of plugins - it's not always obvious how it's going to work in different operating systems. And I think we all agree that the current result isn't OK.

This is why we have beta releases of Fedora. Would it have been nice to catch this earlier? Of course. Unfortunately, GNOME Software was in a pretty big state of flux this cycle, and furthermore, not a lot of Rawhide users use GNOME Software as a way to install RPMs.

So, thanks for noticing this, Neal!

We discussed this at today's WG meeting.

There are some differences of opinion on the group regarding whether it is ever appropriate to use language like "safe" and "unsafe" in relation to app security, and what the best long-term strategy is for improving the security of desktop apps.

However, there is a consensus that gnome-software F35 shouldn't describe Fedora RPMs as unsafe - it's like we're undermining our own product in front of our users, and will be unsettling/scary for people.

I've taken the action to explore ways to resolve the issue for F35. The most obvious possibilities here would be to either:

1. change the safety categories by giving them new headings, or
2. hide the safety tile entirely.

1 has the challenge that GNOME is in string freeze, but that could hopefully be overcome. 2 wouldn't be as good because the safety dialog includes some useful information that it would be a shame to lose.

If anyone has any other ideas, feel free to add them to the comments.

To be clear, nobody was approaching this from the upstream side with the thought "let's label all non-Flatpak applications as potentially unsafe".

FWIW I very strongly believe we should do that eventually, because with very few exceptions RPM applications are very unsafe. The WG does not agree on this, but it's true. ;)

Regardless, the WG discussed this today and agreed that displaying applications we install ourselves as unsafe is a bad move. The action item here is for @aday to propose some emergency design changes to avoid this terminology.

Er, I had a race condition with Allan it seems. Pagure doesn't stop people from posting when there has been a new comment. Whatever.

1 has the challenge that GNOME is in string freeze, but that could hopefully be overcome.

I doubt i18n team will allow a string freeze break before 41.0 at this point, but I bet it would be allowed for 41.1. Perhaps we could target 41.1 for an upstream solution, while temporarily patching out the tile downstream in the meantime. Does that sound good?

Some wording I suggested in the meeting as an alternative to the too technical "sandboxed":100:

• limited system access
• limited access to your data

There's a GNOME ticket for this now: gnome-software#1450.

The approach that's currently being considered is to classify apps from an official repos as safe, irrespective of the packaging format. This would be done using an existing mechanism which allows us to specify the names of official repos.

The main question I have right now is whether this approach - specifying the names of trusted/official repos - will work in all cases, particularly corporate RHEL deployments.

The approach that's currently being considered is to classify apps from an official repos as safe, irrespective of the packaging format. This would be done using an existing mechanism which allows us to specify the names of official repos.

Philip Withnall has very kindly produced a MR which implements this, which he's pushing to have included in today's gnome-software 41.0 release. It's important that people review this quickly to make sure that it meets our needs.

In addition to the concern about the appropriateness of this for RHEL, another potential issue is where the 3rd party repos will end up, since RPMs will either end up being labelled as "potentially unsafe" or "packaged by your distribution". Perhaps we should request that "packaged by your distribution" should be changed to "reviewed by your distribution"?

The approach that's currently being considered is to classify apps from an official repos as safe, irrespective of the packaging format. This would be done using an existing mechanism which allows us to specify the names of official repos.

Philip Withnall has very kindly produced a MR which implements this, which he's pushing to have included in today's gnome-software 41.0 release. It's important that people review this quickly to make sure that it meets our needs.

This looks great, I let @pwithnall know in the GNOME Software MR, but I'll state it here too: I'm glad we got this quickly resolved!

In addition to the concern about the appropriateness of this for RHEL, another potential issue is where the 3rd party repos will end up, since RPMs will either end up being labelled as "potentially unsafe" or "packaged by your distribution". Perhaps we should request that "packaged by your distribution" should be changed to "reviewed by your distribution"?

I think "reviewed by your distribution" makes more sense, since that will make sense with specific third-party repos we're vetting (NVIDIA driver, Steam, OpenH264, etc.).

@mcrha Can we get this cherry-picked into our package so that F35 Beta has it? I see it's been merged into GNOME Software for GNOME Software 41 final.

I hoped it'll wait for the release, which might be done tomorrow or so, thus getting into Fedora the next week (depending how quick the other GNOME stuff will be released upstream and updated downstream).

If you think it still should go in immediately, separate from the other GNOME 41.0 releases, then I can create an f35 update now. Just let me know.

Kalev told me to do the update with the patch, thus I did it here [1]. The new strings are not translated, but that's kind of expected, I suppose.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-34621917ba

Nice, thanks Milan! Let's see if we can get a freeze exception to get this into Beta.

Freeze Exception ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2005265

Note that we are likely to need follow-up changes to the MR that landed upstream.

If we don't want the 3rd party repos to be labelled as "potentially unsafe", we'll need to add them to the official repos.

This is complicated by the fact that official repos can't be disabled in the repo settings (we previously introduced this behavior to prevent people from disabling the main repos like fedora-updates).

We probably should do that for OpenH264, at least. We do build that.

Agreed. I think we should look at the openh264 repo not so much as a third party repo, but more like as part of Fedora that's just hosted elsewhere.

If we don't want the 3rd party repos to be labelled as "potentially unsafe", we'll need to add them to the official repos.

I agree, but this will be less-noticeable and can wait until after beta so that we don't need to respin the existing update.

BTW I have a longer-term proposal at https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1451#note_1271285 that would eliminate the need for maintaining a list of trusted repos by not checking whether the source is "trusted" at all and just reducing the badness at which we display unsandboxed applications.

The openh264 doesn't come through fedora-third-party, does it? It does not here at least.

I tried with Google Chrome, provided by a repo from the fedora-third-party and it says: "Potentially unsafe" "Provided by a third party; Proprietary code" and in the dialog:
* "Provided by a third party" "Check that you trust the vendor, as the application is not sandboxed"
* "Proprietary code" "The source code is not public, so it cannot be independently audited and might be unsafe"
while when I patch gnome-software with , then it says: "Potentially unsafe" "Proprietary code" and in the dialog:
* "Reviewed by your distribution" "Application isn't sandboxed but the distribution has checked that it is not malicious"
* "Proprietary code" "The source code is not public, so it cannot be independently audited and might be unsafe"

openh264 comes from fedora-repos. We merely never updated it to be listed as a first party repo.

The fedora-repos is unknown to gnome-software. It used to use fedora-workstation-repositories package, then (in f35) switched to fedora-third-party command line tool.

I mean that the repo definitions are shipped there instead of in fedora-workstation-repositories: https://src.fedoraproject.org/rpms/fedora-repos/blob/rawhide/f/fedora-cisco-openh264.repo

The following repo identifiers need to be added to the trusted set:

• fedora-cisco-openh264
• fedora-cisco-openh264-debuginfo

PR for that: https://src.fedoraproject.org/rpms/gnome-software/pull-request/2

The following repo identifiers need to be added to the trusted set:

Okay, I've it prepared locally, added to the official-repos settings key, it will be committed with the 41.0 release.

I proposed the patch from the comment https://pagure.io/fedora-workstation/issue/244#comment-752234 as https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/998 , with more related changes around the fedora-third-party tool in the gnome-software.

This is unrelated to the app safety claim, but it's related to the official-repos key: could someone interested give a voice here [1], please?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2010353

Confirmed that this issue is fixed in gnome-software 41.0