F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications

== Summary ==
Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub.


== Detailed Description ==
'''''Note that this proposal is about user experience, procedures,
and
technology - the high-level concept has already been discussed and
approved by the Fedora Council and FESCO.'''''

Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub. This means that applications on
Flathub that have been explicitly approved (by a new process proposed
here) will be available in GNOME Software and on the
<code>flatpak</code> command line. If the user follows following the
instructions on https://flatpak.org/setup/Fedora/, then the filter is
removed, and the user gets a full view of Flathub.

Roughly speaking, the criteria for including software is a) will not
cause legal or other problems for Fedora to point to b) does not
overlap Fedora Flatpaks or software in Fedora that could easily be
made into a Flatpak c) works reasonably well. For Fedora 35, We expect
to include all software from the top 50 most popular applications on
Flathub that meet these criteria plus selected other software of
interest to the Fedora target audience - Fedora community members are
welcome to propose additions.

Already reviewed: Zoom, Microsoft Teams, Skype, Bitwarden, Postman,
Minecraft<br>
Other likely software from the top 50: Discord, Anydesk, WPS Office,
OnlyOffice, MasterPDFEditor, Slack, UngoogledChromium, Flatseal,
WhatsAppQT, GreenWithEnvy

The expectation is that many included applications will be things that
are hard or impossible to package in Fedora - proprietary
applications, Electron-based applications, and so forth. This is
consistent with the third-party software policy, and does not reflect
a change from what we do currently with third-party repositories.

Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/108 #108 Add selected
Flathub apps to the third-party repos]

== Conformance to Fedora policies ==

The goal here is to be in conformance with the Fedora
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]. The current form of this policy was
explicitly written and approved with the filtered view of Flathub
being one of the use cases. See
https://pagure.io/fesco/fesco-docs/pull-request/34

In detail, this proposal meets
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/...
Key requirements for third-party repositories]. We consider each
application included in the filter as a separate "mini" repository

<blockquote>
Third-party repositories must be approved by an active Fedora working
group or SIG, or by FESCo. Groups who approve the inclusion of third
party repositories must have a documented process which allows for
community input, which produces a traceable history for each decision
(for example, a ticket or other record).
</blockquote>

The traceable process is filing a merge request to
https://pagure.io/fedora-flathub-filter/

<blockquote>
Additionally, repositories included in an edition or spin’s
third-party repository list must conform to the following
requirements:

* Just as with any software hosted by Fedora, third party repositories
must not contain material that poses an undue legal risk for the
Fedora Project or its sponsors. This risk includes, but is not limited
to, software with known patent issues, copyright issues, or software
tailored for conducting illegal activities. Fedora working groups
should evaluate if a proposed addition or provider poses a significant
risk, and if in doubt, confer with Fedora Legal for advice.
</blockquote>

This is done for each pull request to the `fedora-flathub-filter` repository.

<blockquote>
* Changes made by one Edition or spin should not impact other Fedora
editions or spins.
</blockquote>

Each spin has the ability to include filtered view of Flathub or not.
We do not foresee having *separate* filters for different spins.

<blockquote>
* Working groups and SIGs should maintain oversight over the software
that is made available through third-party repositories, to prevent
unvetted software being made available to Fedora users. As part of
this, third-party repositories should allow easy auditing by Fedora
Legal. This requirement implies that third-party repositories should
limit themselves to a small number of packages, or that measures
should be put in place to define which packages are made available
from a particular repository by default.
</blockquote>

The filter is a "measure ... to define which packages are made available".

== Technical implementation ==

* The <code>fedora-third-party</code> script added by
[[Changes/Third_Party_Software_Mechanism]] will also include support
for Flatpak repositories.
* A new package <code>fedora-flathub-repository</code> will be added
with a configuration file
<code>/etc/fedora-third-party.d/flathub.conf</code> and a file
<code>/etc/flatpak/filters/fedora-flathub.filter</code> that is
referenced by the <code>flathub</code> remote when created.
* The filter is maintained by the scripts and procedures in
https://pagure.io/fedora-flathub-filter/ - additions correspond to
pull requests.
* If the user explicitly installs Flathub, by, for example, following
the instructions on https://flatpak.org/setup/Fedora/, then the filter
is removed, and the user gets a full view of Flathub. (This is
standard behavior already implemented in the Flatpak client)


== Benefit to Fedora ==
Fedora users who opt-in to third-party software repositories will have
immediate access to more software out-of-the-box.

== Scope ==
* Proposal owners
** Add flatpak support to the `fedora-third-party` script
** Add a `fedora-flathub-repository` package that is built from the
output of `fedora-flathub-filter` and integrates with the
`fedora-third-party` repository package.
* Other developers:
** No actions needed
* Release engineering: [https://pagure.io/releng/issue/10187 #10187]
** No actions needed
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No significant alignment

== Upgrade/compatibility impact ==
The expectation is that:
* If the system already has a flathub remote installed, nothing
happens, whether or not the user has opted-in to third-party software.
* If the system does not have a flathub remote installed, and the user
opts-in to third-party software at upgrade time, then the filtered-in
apps are then available.

== How To Test ==
* On a fresh install or upgrade, if the user opts-in to third-party
software, applications such as Skype are visible in GNOME Software and
`flatpak search`.
* On a fresh install or upgrade, if the user does not opt-in to
third-party software, applications such as Skype are not visible in
GNOME Software and `flatpak search`.
* If https://flatpak.org/setup/Fedora/ is followed before upgrade, the
remote remains unfiltered.
* If https://flatpak.org/setup/Fedora/ is followed after upgrade, the
remote becomes unfiltered.

== User Experience ==
Fedora users who opt-in to third-party software repositories will have
immediate access to more software out-of-the-box.

== Dependencies ==
This depends on [[Changes/Third_Party_Software_Mechanism]]

== Contingency Plan ==
* Contingency mechanism: remove the dependency of
fedora-workstation-release on `fedora-flathub-repository`
* Contingency deadline: release candidate
* Blocks release? No - the contingency plan could be used at any point

== Documentation ==
The review process is described at https://pagure.io/fedora-flathub-filter/

== Release Notes ==
With Fedora 35, if the user opts-in to third-party software
repositories selected applications from https://flathub.org are now
available by default in GNOME Software, in KDE Discover, and on the
Flatpak command line.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Vitaly Zaitsev]

On 29/06/2021 22:25, Ben Cotton wrote:
>  Enabling third-party repositories will now create a Flathub remote
>  that is a filtered view of Flathub. 
I don't trust Flathub at all, because they don't want to register a 
non-profit organization. They can easily sell their business like 
FreeNode did recently.

Flathub relies on upstreams, not professional maintainers. Most of 
upstream developers don't know how to package software properly. They 
bundle lots of libraries, don't use C/C++ build hardening flags, etc.

A lot of applications from Flathub uses --filesystem=host or 
--filesystem=home, which means they don't use Flatpak isolation at all.

Due to the bundling of a large number of libraries, some applications 
have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284, 
CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780.

>  Roughly speaking, the criteria for including software is a) will not
>  cause legal or other problems for Fedora to point to b) does not
>  overlap Fedora Flatpaks or software in Fedora that could easily be
>  made into a Flatpak c) works reasonably well. 
Should be added also:

d) doesn't exists in Fedora RPM repositories.

>  Fedora users who opt-in to third-party software repositories will
> have
>  immediate access to more software out-of-the-box. 

Fedora Silverblue must have its own Flatpaks and do not rely on 
third-party repositories.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miro Hrončok]

On 30. 06. 21 12:41, Vitaly Zaitsev via devel wrote:
>  I don't trust Flathub at all, because they don't want to
> register a non-profit 
>  organization. They can easily sell their business like FreeNode did recently. 
Similar situation as with the Fedora Project, I must say.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Vitaly Zaitsev]

On 30/06/2021 12:57, Miro Hrončok wrote:
>  Similar situation as with the Fedora Project, I must say. 
Yes. Fedora's infra belongs to Red Hat, Inc.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Michael Catanzaro]

On Wed, Jun 30 2021 at 12:41:17 PM +0200, Vitaly Zaitsev via devel 
<devel(a)lists.fedoraproject.org&gt; wrote:
>   They
>  bundle lots of libraries, 
Well that's required for anything not present in the runtime.

>  don't use C/C++ build hardening flags, etc. 
I believe hardening flags are added in by flatpak-builder. I think they 
somehow come from the runtime, though I'm not sure exactly how. 
(Anybody know?)

For freedesktop-sdk and the GNOME SDK, the hardening flags are actually 
copied straight from Fedora with only minor adjustments. E.g. GCC is 
built with --enable-default-pie --enable-default-ssp so the runtime 
doesn't need to use GCC specs in the default flags like Fedora does. 
Again, since applications do get these flags (somehow), they have to go 
out of their way to screw this up.

(Seriously, how do the applications inherit the hardening flags? It 
can't be via magic. We should confirm that this actually works.)

>  A lot of applications from Flathub uses --filesystem=host or
--filesystem=home, which means they don't use Flatpak isolation at all.

This is true. However, for most Fedora editions, it's also irrelevant, 
because RPMs are entirely unsandboxed and banning poorly-sandboxed 
flatpak applications doesn't make sense when you can just install 
completely unsandboxed RPM applications.

For Silverblue, it would make sense IMO to be stricter and filter 
poorly-sandboxed applications out of GNOME Software.

Michael

[Kalev Lember]

On Wed, Jun 30, 2021 at 2:31 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  I believe hardening flags are added in by flatpak-builder. I think
> they
>  somehow come from the runtime, though I'm not sure exactly how.
>  (Anybody know?)
>  
Yes: there's a flatpak-builder config file in
/etc/flatpak-builder/defaults.json that's part of the runtime that adds the
hardening flags.

-- 
Kalev

[Vitaly Zaitsev]

On 30/06/2021 14:30, Michael Catanzaro wrote:
>  Well that's required for anything not present in the runtime.
That's why I prefer classic RPM packages over Flatpaks.

I use Flatpaks only for proprietary software like Steam (with a lot of 
permission hardening overrides).

>  I believe hardening flags are added in by flatpak-builder. I think
> they somehow come from the runtime, though I'm not sure exactly how. (Anybody know?) 
Yes, but some developers think they are smarter than runtime maintainers 
and explicitly explicitly ignore them. I've previously reported such 
incidents.

>  However, for most Fedora editions, it's also irrelevant, because
> RPMs are entirely unsandboxed and banning poorly-sandboxed flatpak applications
> doesn't make sense when you can just install completely unsandboxed RPM applications.
Flatpak is being advertised as a safe and secure environment for running 
desktop applications.

Flatpak with access to user's home directory can do everything: change 
Flatpak policies, add/remove Flatpak repositories, override security 
permissions, etc.

I think Flatpaks with --filesystem=host or --filesystem=home should be 
banned too. Flathub admins don't consider this a security breach.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Owen Taylor]

On Wed, Jun 30, 2021 at 6:42 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 29/06/2021 22:25, Ben Cotton wrote:
>  > Enabling third-party repositories will now create a Flathub remote
>  > that is a filtered view of Flathub.
>
>  I don't trust Flathub at all, because they don't want to register a
>  non-profit organization. They can easily sell their business like
>  FreeNode did recently. 
Setting up an independent non-profit, and maintaining it's non-profit
status is a quite involved activity. (details depend on the country,
of course!)

Flathub's non-donated hardware resources are owned by the GNOME
Foundation (a registered non-profit) and the GNOME Foundation also
owns the Flathub trademark (See:
https://foundation.gnome.org/logo-and-trademarks/). Hopefully this
provides some assurance that Flathub won't suddenly start doing
something entirely different.

If we lost trust in Flathub, Fedora would also have the ability to
update the filter to have *no* applications in it.

>  Flathub relies on upstreams, not professional maintainers. Most of
>  upstream developers don't know how to package software properly. They
>  bundle lots of libraries, don't use C/C++ build hardening flags, etc. 
Flathub is a packaging community, like Fedora. Being a professional is
definitely not a criteria for contributing to Fedora. :-)

>  A lot of applications from Flathub uses --filesystem=host or
>  --filesystem=home, which means they don't use Flatpak isolation at all. 
This is something that definitely can be and will be examined when
reviewing applications for inclusion in the Fedora filter.
Unfortunately, a lot of interesting software can't be completely
sandboxed - because it, say, uses X11 rather than Wayland. But where
thing *can* be sandboxed they should be sandboxed.

>  Due to the bundling of a large number of libraries, some
> applications
>  have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284,
>  CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780. 
There are definitely improvements that could be made to CVE response
policies in Flathub, and I know automated scanning was being worked
on. If we were activitely looking to delegate software that is
packaged in Fedora to Flathub, I think we'd need to have a very high
bar here. But as a source of *additional* software, I think the
standard should be comparison to wherever the Fedora user would get
the software from otherwise. When this is scheduled for FESCO
discussion, I'll try to see if we can get some Flathub maintainers to
attend in case people have questions in this area (or other areas).

>  > Roughly speaking, the criteria for including software is a) will
> not
>  > cause legal or other problems for Fedora to point to b) does not
>  > overlap Fedora Flatpaks or software in Fedora that could easily be
>  > made into a Flatpak c) works reasonably well.
>
>  Should be added also:
>
>  d) doesn't exists in Fedora RPM repositories. 
The text you qouoted said "or software in Fedora that could easily be
made into a Flatpak" - I left some wiggle room there, but certainly if
we were including anything that overlapped Fedora RPMs, one of two
things would need to be true:

 * Installation from Flathub would need to be prioritized after
installation from Fedora RPMs
 * Fedora Silverblue would need it's own filter list with additional
applications

In the immediate future, our plan is to avoid any such overlap.

>  > Fedora users who opt-in to third-party software repositories
> will have
>  > immediate access to more software out-of-the-box.
>
>  Fedora Silverblue must have its own Flatpaks and do not rely on third-party repositories.
This is not about replacing software that is included in Fedora. It's
about providing access to software *not* included in Fedora.

Thanks for the feedback!
Owen


- Owen

[Vitaly Zaitsev]

On 30/06/2021 14:44, Owen Taylor wrote:
>  Setting up an independent non-profit, and maintaining it's
> non-profit
>  status is a quite involved activity. (details depend on the country,
>  of course!) 
If Flathub want to be a trustworthy repository, it should be done.

>  Hopefully this
>  provides some assurance that Flathub won't suddenly start doing
>  something entirely different. 
No, it doesn't. FreeNode situation is an example.

>  If we lost trust in Flathub, Fedora would also have the ability to
>  update the filter to have *no* applications in it. 
Every application with --filesystem=host or --filesystem=home can drop 
all filters, enable new repositories, etc.

>  Flathub is a packaging community, like Fedora. Being a professional
> is
>  definitely not a criteria for contributing to Fedora. 
All Fedora packagers must be sponsored first and they know at least 
Fedora packaging guidelines. On Flathub anyone can add anything.

>  This is something that definitely can be and will be examined when
>  reviewing applications for inclusion in the Fedora filter. 
This is not a panacea. Some Flathub maintainers added --filesystem=host 
or --filesystem=home after the initial review.

>  Unfortunately, a lot of interesting software can't be completely
>  sandboxed - because it, say, uses X11 rather than Wayland. 
X11 is not a problem. Btw, a lot of Qt applications from Flathub 
explicitly uses X11 over Wayland due to buggy downstream patch:

https://github.com/flathub/com.kristianduske.TrenchBroom/blob/98a3b8a6e55...
https://github.com/flathub/org.kde.kolourpaint/blob/0527e34fabb41cba37c67...
https://github.com/flathub/com.chatterino.chatterino/blob/18e03ca830f28ea...
https://github.com/flathub/org.openhantek.OpenHantek6022/blob/6fa7f8c357f...
https://github.com/flathub/com.rosegardenmusic.rosegarden/blob/8ac254753f...
https://github.com/flathub/org.electrum.electrum/blob/7a3867719cb20ee22e7...
https://github.com/flathub/com.github.fontmatrix.Fontmatrix/blob/49fdebbf...
https://github.com/flathub/uk.org.zint.zint-qt/blob/f6c30cfe2858bada7785a...
https://github.com/flathub/org.avidemux.Avidemux/blob/75ffac52c85cc1ceb10...
https://github.com/flathub/org.dash.electrum.electrum_dash/blob/fdad9ec43...
https://github.com/flathub/org.hydrogenmusic.Hydrogen/blob/425efc134dfa9f...
https://github.com/flathub/org.musescore.MuseScore/blob/c2a2f112f34538c2e...
https://github.com/flathub/io.lmms.LMMS/blob/1a7c3f8780794c2fd3d088a24ac1...
https://github.com/flathub/org.kde.okular/blob/7e4f34ccf6e86eaf3f42222ad5...
https://github.com/flathub/net.scribus.Scribus/blob/9f6bebb19e52524243758...
https://github.com/flathub/org.mixxx.Mixxx/blob/da784e9b76cb1c30440116489...
https://github.com/flathub/org.freecadweb.FreeCAD/blob/abbc05c0ff45d3e59f...
https://github.com/flathub/org.kde.kontact/blob/2d277bd9054141b831e02ebe7...

>  The text you qouoted said "or software in Fedora that could
> easily be
>  made into a Flatpak" - I left some wiggle room there, but certainly if
>  we were including anything that overlapped Fedora RPMs, one of two
>  things would need to be true: 
Fixed version:

d) doesn't exists in Fedora RPM repositories (except ostree-based Fedora 
editions).

>  Installation from Flathub would need to be prioritized after
>  installation from Fedora RPMs 
Gnome Sofware already prioritizes Flatpaks over RPM packages even on 
Workstation Edition. I don't like that.

Flatpaks prioritization should only be done on ostree versions.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Owen Taylor]

On Wed, Jun 30, 2021 at 9:26 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  On 30/06/2021 14:44, Owen Taylor wrote:
>  > Setting up an independent non-profit, and maintaining it's non-profit
>  > status is a quite involved activity. (details depend on the country,
>  > of course!)
>
>  If Flathub want to be a trustworthy repository, it should be done.
>
>  > Hopefully this
>  > provides some assurance that Flathub won't suddenly start doing
>  > something entirely different.
>
>  No, it doesn't. FreeNode situation is an example. 
While the GNOME Foundation could license or transfer the Flathub name
to a commercial entity if it determined it was in the public's best
interest, so could a hypothetical Flathub Foundation. In the end,
Fedora doesn't have a lot of leverage to demand that the Flathub
community organize itself as an independent non-profit! That being
said, if we get some Flathub maintainers to come to the FESCO meeting,
I'm sure they would be happy to answer questions about how Flathub is
run and decisions are made.

>  > If we lost trust in Flathub, Fedora would also have the ability
> to
>  > update the filter to have *no* applications in it.
>
>  Every application with --filesystem=host or --filesystem=home can drop
>  all filters, enable new repositories, etc. 
There's a distinction to be made between dubious behavior (inserting
ads in applications, say) and out-and-out malware. My comment was
aimed at the former - different things would need to be done in the
latter case. I don't see any reason to expect Flathub to be knowingly
engaging in either. We currently offer various third-party RPM
repositories where the packages run without any sandboxing at all.

>  > Flathub is a packaging community, like Fedora. Being a
> professional is
>  > definitely not a criteria for contributing to Fedora.
>
>  All Fedora packagers must be sponsored first and they know at least
>  Fedora packaging guidelines. On Flathub anyone can add anything.
>
>  > This is something that definitely can be and will be examined when
>  > reviewing applications for inclusion in the Fedora filter.
>
>  This is not a panacea. Some Flathub maintainers added --filesystem=host
>  or --filesystem=home after the initial review. 
I would imagine that when it happens, it's typically not because the
maintainer is trying to sneak something over on their users (and users
will get prompted on upgrade), but because it turned out there were
issues with the more restrictive permissions.

The main point of sandboxing is not to protect the users against the
Flathub maintainers, or the app authors. It's to protect the users
from malicious actors exploiting vulnerabilities in the application.
By checking that the application has reasonable permissions at review
time, we can get some idea of whether the Flathub maintainer knows how
to use permissions, but yes, we are delegating some trust to Flathub
here in the case where this changes.

The Flatpak and Flathub communities would definitely appreciate help
in figuring out how to nudge Flatpak packagers and application authors
towards more restrictive permissions.

- Owen

[Ian McInerney]

On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
>
>  == Summary ==
>  Enabling third-party repositories will now create a Flathub remote
>  that is a filtered view of Flathub.
>
>
>  == Detailed Description ==
>  '''''Note that this proposal is about user experience, procedures,
> and
>  technology - the high-level concept has already been discussed and
>  approved by the Fedora Council and FESCO.'''''
>
>  Enabling third-party repositories will now create a Flathub remote
>  that is a filtered view of Flathub. This means that applications on
>  Flathub that have been explicitly approved (by a new process proposed
>  here) will be available in GNOME Software and on the
>  <code>flatpak</code> command line. If the user follows following the
>  instructions on https://flatpak.org/setup/Fedora/, then the filter is
>  removed, and the user gets a full view of Flathub.
>
>  Roughly speaking, the criteria for including software is a) will not
>  cause legal or other problems for Fedora to point to b) does not
>  overlap Fedora Flatpaks or software in Fedora that could easily be
>  made into a Flatpak c) works reasonably well. For Fedora 35, We expect
>  to include all software from the top 50 most popular applications on
>  Flathub that meet these criteria plus selected other software of
>  interest to the Fedora target audience - Fedora community members are
>  welcome to propose additions.
>  
Does this mean that FESCO is now forcing Fedora packagers to maintain
Fedora Flatpaks and respond to their related issues when many of them seem
to be created without the packagers' knowledge/consent, and there is no
documentation in the packaging guidelines/wiki about how to actually do
anything for them, or information about where the manifests for them
actually live?

-Ian

[Neal Gompa]

On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney <ian.s.mcinerney(a)ieee.org&gt; wrote:
>  On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
> >
> > == Summary ==
> > Enabling third-party repositories will now create a Flathub remote
> > that is a filtered view of Flathub.
> >
> >
> > == Detailed Description ==
> > '''''Note that this proposal is about user experience,
> procedures, and
> > technology - the high-level concept has already been discussed and
> > approved by the Fedora Council and FESCO.'''''
> >
> > Enabling third-party repositories will now create a Flathub remote
> > that is a filtered view of Flathub. This means that applications on
> > Flathub that have been explicitly approved (by a new process proposed
> > here) will be available in GNOME Software and on the
> > <code>flatpak</code> command line. If the user follows following the
> > instructions on https://flatpak.org/setup/Fedora/, then the filter is
> > removed, and the user gets a full view of Flathub.
> >
> > Roughly speaking, the criteria for including software is a) will not
> > cause legal or other problems for Fedora to point to b) does not
> > overlap Fedora Flatpaks or software in Fedora that could easily be
> > made into a Flatpak c) works reasonably well. For Fedora 35, We expect
> > to include all software from the top 50 most popular applications on
> > Flathub that meet these criteria plus selected other software of
> > interest to the Fedora target audience - Fedora community members are
> > welcome to propose additions.
>
>
>  Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora Flatpaks and
> respond to their related issues when many of them seem to be created without the
> packagers' knowledge/consent, and there is no documentation in the packaging
> guidelines/wiki about how to actually do anything for them, or information about where the
> manifests for them actually live?
>  
Of course not. This is a criteria for what we permit through the
filter from Flathub. The idea is that nothing we offer from Flathub
should be possible to ship in Fedora itself. That is, it's truly only
possible to be available as a third-party app.

Basically, if something is available in Fedora, it *cannot* be
available through Flathub by default.




--
真実はいつも一つ！/ Always, there's only one truth!

[Ian McInerney]

On Wed, Jun 30, 2021 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney
> <ian.s.mcinerney(a)ieee.org&gt;
>  wrote:
>  >
>  > On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >>
>  >> https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
>  >>
>  >> == Summary ==
>  >> Enabling third-party repositories will now create a Flathub remote
>  >> that is a filtered view of Flathub.
>  >>
>  >>
>  >> == Detailed Description ==
>  >> '''''Note that this proposal is about user experience,
> procedures, and
>  >> technology - the high-level concept has already been discussed and
>  >> approved by the Fedora Council and FESCO.'''''
>  >>
>  >> Enabling third-party repositories will now create a Flathub remote
>  >> that is a filtered view of Flathub. This means that applications on
>  >> Flathub that have been explicitly approved (by a new process proposed
>  >> here) will be available in GNOME Software and on the
>  >> <code>flatpak</code> command line. If the user follows following
> the
>  >> instructions on https://flatpak.org/setup/Fedora/, then the filter is
>  >> removed, and the user gets a full view of Flathub.
>  >>
>  >> Roughly speaking, the criteria for including software is a) will not
>  >> cause legal or other problems for Fedora to point to b) does not
>  >> overlap Fedora Flatpaks or software in Fedora that could easily be
>  >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect
>  >> to include all software from the top 50 most popular applications on
>  >> Flathub that meet these criteria plus selected other software of
>  >> interest to the Fedora target audience - Fedora community members are
>  >> welcome to propose additions.
>  >
>  >
>  > Does this mean that FESCO is now forcing Fedora packagers to maintain
>  Fedora Flatpaks and respond to their related issues when many of them seem
>  to be created without the packagers' knowledge/consent, and there is no
>  documentation in the packaging guidelines/wiki about how to actually do
>  anything for them, or information about where the manifests for them
>  actually live?
>  >
>
>  Of course not. This is a criteria for what we permit through the
>  filter from Flathub. The idea is that nothing we offer from Flathub
>  should be possible to ship in Fedora itself. That is, it's truly only
>  possible to be available as a third-party app.
>
>  Basically, if something is available in Fedora, it *cannot* be
>  available through Flathub by default.
>  
But that is exactly why it seems to me packagers are being forced to care
about the Fedora Flatpaks. Take the Audacity package as an example (since I
am one of the people maintaining it). There is a usable Flatpak for it on
Flathub, and I as a packager don't want to need to learn the Fedora systems
to build and maintain a Fedora Flatpak for it (since there seems to be
little to no documentation on how to do it). According to this policy -
since there is an Audacity package in Fedora, the Flathub version couldn't
be included. If we don't have a maintained version of the Flatpak in
Fedora, then why are we blocking it from Flathub?

-Ian

[Neal Gompa]

On Wed, Jun 30, 2021 at 8:09 AM Ian McInerney <ian.s.mcinerney(a)ieee.org&gt; wrote:
>  On Wed, Jun 30, 2021 at 12:47 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > On Wed, Jun 30, 2021 at 7:43 AM Ian McInerney <ian.s.mcinerney(a)ieee.org&gt;
> wrote:
> > >
> > > On Tue, Jun 29, 2021 at 9:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
> > >>
> > >> https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
> > >>
> > >> == Summary ==
> > >> Enabling third-party repositories will now create a Flathub remote
> > >> that is a filtered view of Flathub.
> > >>
> > >>
> > >> == Detailed Description ==
> > >> '''''Note that this proposal is about user experience,
> procedures, and
> > >> technology - the high-level concept has already been discussed and
> > >> approved by the Fedora Council and FESCO.'''''
> > >>
> > >> Enabling third-party repositories will now create a Flathub remote
> > >> that is a filtered view of Flathub. This means that applications on
> > >> Flathub that have been explicitly approved (by a new process proposed
> > >> here) will be available in GNOME Software and on the
> > >> <code>flatpak</code> command line. If the user follows following
> the
> > >> instructions on https://flatpak.org/setup/Fedora/, then the filter is
> > >> removed, and the user gets a full view of Flathub.
> > >>
> > >> Roughly speaking, the criteria for including software is a) will not
> > >> cause legal or other problems for Fedora to point to b) does not
> > >> overlap Fedora Flatpaks or software in Fedora that could easily be
> > >> made into a Flatpak c) works reasonably well. For Fedora 35, We expect
> > >> to include all software from the top 50 most popular applications on
> > >> Flathub that meet these criteria plus selected other software of
> > >> interest to the Fedora target audience - Fedora community members are
> > >> welcome to propose additions.
> > >
> > >
> > > Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora
> Flatpaks and respond to their related issues when many of them seem to be created without
> the packagers' knowledge/consent, and there is no documentation in the packaging
> guidelines/wiki about how to actually do anything for them, or information about where the
> manifests for them actually live?
> > >
> >
> > Of course not. This is a criteria for what we permit through the
> > filter from Flathub. The idea is that nothing we offer from Flathub
> > should be possible to ship in Fedora itself. That is, it's truly only
> > possible to be available as a third-party app.
> >
> > Basically, if something is available in Fedora, it *cannot* be
> > available through Flathub by default.
>
>
>  But that is exactly why it seems to me packagers are being forced to care about the
> Fedora Flatpaks. Take the Audacity package as an example (since I am one of the people
> maintaining it). There is a usable Flatpak for it on Flathub, and I as a packager
> don't want to need to learn the Fedora systems to build and maintain a Fedora Flatpak
> for it (since there seems to be little to no documentation on how to do it). According to
> this policy - since there is an Audacity package in Fedora, the Flathub version
> couldn't be included. If we don't have a maintained version of the Flatpak in
> Fedora, then why are we blocking it from Flathub?
>  
Because most people are able to install RPMs *and* Flatpaks. And
there's a process for auto-building Flatpaks from our RPM spec
definitions that can use for apps packaged in Fedora.

But most importantly, a large chunk of the applications on Flathub
include stuff we can't directly recommend for various reasons
(patent-encumbered stuff, etc.).



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Owen Taylor]

On Wed, Jun 30, 2021 at 7:44 AM Ian McInerney <ian.s.mcinerney(a)ieee.org&gt; wrote:

> > Roughly speaking, the criteria for including software is a) will
> not
> > cause legal or other problems for Fedora to point to b) does not
> > overlap Fedora Flatpaks or software in Fedora that could easily be
> > made into a Flatpak c) works reasonably well. For Fedora 35, We expect
> > to include all software from the top 50 most popular applications on
> > Flathub that meet these criteria plus selected other software of
> > interest to the Fedora target audience - Fedora community members are
> > welcome to propose additions.
>
>  Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora Flatpaks and
> respond to their related issues when many of them seem to be created without the
> packagers' knowledge/consent, and there is no documentation in the packaging
> guidelines/wiki about how to actually do anything for them, or information about where the
> manifests for them actually live? 
This proposal doesn't really change anything with respect to Fedora
Flatpaks. (Docs for Fedora Flatpaks:
https://docs.fedoraproject.org/en-US/flatpak/)

Are you concerned that there's some implicit threat that if you don't
create a Fedora Flatpak for your Fedora RPM, users will be directed to
the Flathub version? We're really not anticipating overlap between the
set of applications packaged in Fedora and the set included in the
filtered-view of Flathub. Any exceptions to that would definitely have
to be coordinated closely with the relevant package maintainer.

Owen

[Fabio Valentini]

On Tue, Jun 29, 2021 at 10:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
>
>  == Summary ==
>  Enabling third-party repositories will now create a Flathub remote
>  that is a filtered view of Flathub. 
I have a few questions / concerns with this proposal, primarily these two:

1. I wonder if this might be a possible source of confusion /
frustration for users. Examples:
- "Why are my local search results not showing application X from flathub?"
- "Why can't I install application X when I have flathub repo enabled?
It is listed on the flathub website."

2. How is the replacement with unfiltered flathub remote implemented?
Looking at the instructions on flathub.org, this adds a new remote
with the "--if-not-exists" flag.
If the remote already exists, wouldn't that command just do nothing,
and leave the filtered, existing remote in place?
Is this done with ugly hard-coded non-upstreamable hackery in the
"flatpak remote-add" command on Fedora? I hope not ...

Fabio

[Owen Taylor]

On Sat, Jul 3, 2021 at 6:14 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Jun 29, 2021 at 10:26 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
>  >
>  > == Summary ==
>  > Enabling third-party repositories will now create a Flathub remote
>  > that is a filtered view of Flathub.
>
>  I have a few questions / concerns with this proposal, primarily these two:
>
>  1. I wonder if this might be a possible source of confusion /
>  frustration for users. Examples:
>  - "Why are my local search results not showing application X from flathub?"
>  - "Why can't I install application X when I have flathub repo enabled?
>  It is listed on the flathub website." 
Yes, this is a bit of a concern. It would be nice to be able to show
that the repo is the Fedora-filtered version in the 'flatpak-remotes'
list and in the GNOME Software dialog.  We'll think about if there is
some way to handle this nicely. Maybe we could get a patch upstream to
add a 'FilterNote=Fedora Selections' that gets removed along with the
Filter (see below).

>  2. How is the replacement with unfiltered flathub remote
> implemented?
>  Looking at the instructions on flathub.org, this adds a new remote
>  with the "--if-not-exists" flag.
>  If the remote already exists, wouldn't that command just do nothing,
>  and leave the filtered, existing remote in place?
>  Is this done with ugly hard-coded non-upstreamable hackery in the
>  "flatpak remote-add" command on Fedora? I hope not ... 
No, there's code for this already upstream. Quoting from the
flatpak-flatpakrepo(5) man page:

       Filter (string)
           The path of a local file to use to filter remote refs. See
flatpak-remote-add(1) for details on the format of the file.

           Note: This field is treated a bit special by flatpak
remote-add. If you install a remote with --if-not-exists then and the
remote
           is already configured, then the filter field of the remote
configuration will be update anyway. And, if the filter field is *not*
           specified then any existing filters are cleared. The goal
here is to allow a pre-configured filtered remote to be replaced with
the
           regular one if you add the normal upstream (unfiltered)
flatpakrepo file.

Regards,
Owen

[Josh Berkus]

Ben, FESCO:

Thank you for your decision to destroy Silverblue, the best thing Fedora has done in the
last 10 years.

The only thing that makes Silverblue useful -- indeed, superior -- as a desktop is the
ready availability of Flatpaks for any application the user could want. Unlike
old-fashioned Fedora, modifying Fedora to accept the regular Flathub is a multi-step
operation, and not one that's easy for standard users.  This has allowed us to finally
break out of the longstanding Fedora issue of "Sorry, I can't access that app
because I'm on Fedora".

For the last 3 years, Silverblue has spread through the developer ecosystem because
it's the best immutable desktop.  For a short time I dared hope that  we'd retake
desktop primacy from Ubuntu!  But I should have known better.

If another vendor like Ubuntu or Docker were to do this kind of surprise filtering of
apps, Fedora would attack it and write long blogs taking a stance on user choice and
against vendors using their influence to spread vertical monopolies.  But I guess it's
OK if Fedora does it?

If y'all want folks to use Fedora Flatpaks instead of Flathub ones, the answer is to
**make more applications available** via Fedora Flatpaks. Not to restrict user choice
through underhanded BS like this move.

[Matthew Miller]

On Mon, Jul 19, 2021 at 03:58:46PM -0000, Josh Berkus wrote:
>  Thank you for your decision to destroy Silverblue, the best thing
> Fedora has done in the last 10 years. 
Um. This seems a little over-dramatic.

>  If another vendor like Ubuntu or Docker were to do this kind of
> surprise
>  filtering of apps, Fedora would attack it and write long blogs taking a
>  stance on user choice and against vendors using their influence to spread
>  vertical monopolies. But I guess it's OK if Fedora does it? 
The policy is there for a reason -- we can't include arbitary software in
pre-configured repositories. This is a way to broaden what can be available
out of the box to users. That does not seem, to me, like the end of the
world you are painting it to be here.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Josh Berkus]

Matt,

You're correct, I was being very dramatic.  I've since talked to Otaylor, and the
only real problem is that the announcement of this change is misleading.  Fedora isn't
"filtering" anything, you're adding Flathub packages in a place they
weren't available before.  The announcement reads like you're modifying the
Flatpak binary to allow only filtered content, and I think you can see why that would
create substantial alarm among SB users.

Since I was the one to raise a stink about it, I'm going to work with otaylor to
revise the text of the change announcement so that it'll read as a positive feature
change (which it is) instead of as taking something away.