[Input Requested] Preset support for third-party services

[Stephen Gallagher]

I originally raised this as a question to FESCo[1], but I was asked to
bring it up on the Fedora Devel list. My apologies for taking so long
to get around to it.

While looking into a preset request, I realized that the guidelines[2]
do not say anything at all about enabling default services that are
not packaged in Fedora.

For a specific example: suppose that a particular VM host provides its
guest tools only as a closed-source binary that they ship. Do we
permit them to request the inclusion of their service in presets under
the reasoning that it would enhance users' performance on those
systems, or do we disallow any non-Fedora software from being included
in the presets?

What about a third-party repository that provides a closed-source
service that enhances an open-source project (for example, a
closed-source codec server that works with open-source encoding
software)?


[1] https://pagure.io/fesco/issue/2575
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 27 April 2021 at 21:14, Stephen Gallagher wrote:
>  I originally raised this as a question to FESCo[1], but I was asked
> to
>  bring it up on the Fedora Devel list. My apologies for taking so long
>  to get around to it.
>  
>  While looking into a preset request, I realized that the guidelines[2]
>  do not say anything at all about enabling default services that are
>  not packaged in Fedora.
>  
>  For a specific example: suppose that a particular VM host provides its
>  guest tools only as a closed-source binary that they ship. Do we
>  permit them to request the inclusion of their service in presets under
>  the reasoning that it would enhance users' performance on those
>  systems, or do we disallow any non-Fedora software from being included
>  in the presets?
>  
>  What about a third-party repository that provides a closed-source
>  service that enhances an open-source project (for example, a
>  closed-source codec server that works with open-source encoding
>  software)? 
Our SELinux policy contains rules for software not included in Fedora,
including some proprietary software, so I would say we have a precedent
in other areas.

If the service in question follows the rules then I don't see why it
cannot be included.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 27, 2021 at 11:07:14PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>  On Tuesday, 27 April 2021 at 21:14, Stephen Gallagher wrote:
>  > I originally raised this as a question to FESCo[1], but I was asked to
>  > bring it up on the Fedora Devel list. My apologies for taking so long
>  > to get around to it.
>  > 
>  > While looking into a preset request, I realized that the guidelines[2]
>  > do not say anything at all about enabling default services that are
>  > not packaged in Fedora.
>  > 
>  > For a specific example: suppose that a particular VM host provides its
>  > guest tools only as a closed-source binary that they ship. Do we
>  > permit them to request the inclusion of their service in presets under
>  > the reasoning that it would enhance users' performance on those
>  > systems, or do we disallow any non-Fedora software from being included
>  > in the presets?
>  > 
>  > What about a third-party repository that provides a closed-source
>  > service that enhances an open-source project (for example, a
>  > closed-source codec server that works with open-source encoding
>  > software)?
>  
>  Our SELinux policy contains rules for software not included in Fedora,
>  including some proprietary software, so I would say we have a precedent
>  in other areas. 
That's a good point.

>  If the service in question follows the rules then I don't see why
> it
>  cannot be included. 
Yeah. For me, the main reason to *not* allow such presets would be if
there was some general principle against mentioning external software.
But if selinux policy does that, presets should be able to too.

Zbyszek

[Kevin Kofler]

Stephen Gallagher wrote:
>  For a specific example: suppose that a particular VM host provides
> its
>  guest tools only as a closed-source binary that they ship. Do we
>  permit them to request the inclusion of their service in presets under
>  the reasoning that it would enhance users' performance on those
>  systems, or do we disallow any non-Fedora software from being included
>  in the presets?
>  
>  What about a third-party repository that provides a closed-source
>  service that enhances an open-source project (for example, a
>  closed-source codec server that works with open-source encoding
>  software)? 
Can't those just ship their own preset files? While the Fedora Packaging 
Guidelines disallow Fedora packages from doing that, the above packages are 
by definition NOT Fedora packages and hence not bound by those Fedora 
Packaging Guidelines.

Third-party repositories can choose whether to maintain a central preset 
list like Fedora does or whether to allow each package to drop in its own 
preset file.

Considering that systemd allows multiple preset files to be present and 
enabled on the system simultaneously, I do not see a good reason why we 
should maintain presets for third-party software in the Fedora preset. I 
also see this as a possible source of name conflicts or even a venue for 
deliberate name hijacking attacks (where a malicious third-party service 
claims to be a default-enabled service from another third party).

        Kevin Kofler

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 28, 2021 at 10:19:31AM +0200, Kevin Kofler via devel wrote:
>  Stephen Gallagher wrote:
>  > For a specific example: suppose that a particular VM host provides its
>  > guest tools only as a closed-source binary that they ship. Do we
>  > permit them to request the inclusion of their service in presets under
>  > the reasoning that it would enhance users' performance on those
>  > systems, or do we disallow any non-Fedora software from being included
>  > in the presets?
>  > 
>  > What about a third-party repository that provides a closed-source
>  > service that enhances an open-source project (for example, a
>  > closed-source codec server that works with open-source encoding
>  > software)?
>  
>  Can't those just ship their own preset files? 
They *could*, but most likely not in a fashion that is flexible enough.
Essentially, shipping presets in the package itself is equivalent to
statically enabling or disabling the services contained in that
package (*). Presets are useful to provide different defaults for
different Fedora flavours. In the case at hand, cloud setup services,
it would be reasonable to include a preset to enable them, but only in
Cloud variants. If the user installs one those packages on
Workstation/KDE/whatever, it makes sense to default to "off".

(*) The admin may creates a local preset override, even for a package
that carries it's own preset files... But when the preset file is
provided by the distro, this is much easier to discover and document
and feels more "official".

>  While the Fedora Packaging Guidelines disallow Fedora packages from
>  doing that, the above packages are by definition NOT Fedora packages
>  and hence not bound by those Fedora Packaging Guidelines. 
True. But by allowing those presets to be carried in the distro, we
make it easier for those third parties to integrate with us and increase
the likelihood that they'll follow our guidelines too.

>  Considering that systemd allows multiple preset files to be present
> and 
>  enabled on the system simultaneously, I do not see a good reason why we 
>  should maintain presets for third-party software in the Fedora preset. I 
>  also see this as a possible source of name conflicts or even a venue for 
>  deliberate name hijacking attacks (where a malicious third-party service 
>  claims to be a default-enabled service from another third party). 
Any rpm that is installed already gets effectively full control over
the system (directly without any effort, if scripts are not disabled,
and they must not be for presets to work). So "name hijacking" would
be an unnecessary detour at that point.

Zbyszek

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
>  They *could*, but most likely not in a fashion that is flexible
> enough.
>  Essentially, shipping presets in the package itself is equivalent to
>  statically enabling or disabling the services contained in that
>  package (*). Presets are useful to provide different defaults for
>  different Fedora flavours. In the case at hand, cloud setup services,
>  it would be reasonable to include a preset to enable them, but only in
>  Cloud variants. If the user installs one those packages on
>  Workstation/KDE/whatever, it makes sense to default to "off". 
Requires: (proprietaryware-preset-cloud if fedora-release-cloud)

>  Any rpm that is installed already gets effectively full control over
>  the system (directly without any effort, if scripts are not disabled,
>  and they must not be for presets to work). So "name hijacking" would
>  be an unnecessary detour at that point. 
True. Still, the potential for name conflicts is there.

        Kevin Kofler