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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
