Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Change the default configuration of '''DNF5/libdnf5''' by setting <code>allow_vendor_change=False</code> via the distribution defaults file <code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code>. This prevents ''libdnf5'' from automatically replacing an installed package from one vendor with a package from another vendor during any transaction (such as upgrades, downgrades, or dependency resolution), unless explicitly requested by the user or allowed by ''VendorChangeManager'' rules.
== Owner == * Name: [[User:jrohel| Jaroslav Rohel]], [[Subprojects/ReleaseEngineering|Fedora Release Engineering / Maintainers]] * Email: jrohel@redhat.com, fedora-release-maintainers@fedoraproject.org
== Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
Any intentional vendor transitions (such as stock Fedora packages being replaced by enhanced versions from RPM Fusion) will be handled either explicitly by the user via CLI configuration overrides or managed gracefully via ''VendorChangeManager'' rules defined in configuration drop-ins.
== Feedback == '''Existing User Requests:''' There have been long-standing community requests and discussions regarding making vendor sticky behavior (in other words, disabling vendor changes by default) the standard configuration in Fedora.
'''Vendor Equivalence & Advanced Rules:''' During previous discussions, a common and critical requirement was the ability to define vendor equivalence classes or establish special transition rules for specific sets of vendors or packages. To address this, ''libdnf5'' has been extended to support granular control over vendor sticky behavior out of the box through its newly designed ''VendorChangeManager'' architecture.
'''Allowing Vendor Change for Specific Packages:''' Community feedback emphasized that users must retain the flexibility to intentionally switch vendors for specific packages without globally disabling the vendor sticky protection. To support this use case, ''libdnf5'' has been enhanced, and the ''DNF5'' command-line interface now includes a dedicated <code>--from-vendor=</code> argument. This allows users to explicitly specify a set of permitted vendors for specific packages during a given transaction, ensuring safe and targeted package migrations.
'''Vendor Verification Override for Command-Line Packages:''' An edge case raised in discussions involved local package installations, where users requested that vendor restrictions be ignored for packages explicitly provided via a direct file system path. This requirement will be addressed as part of the scope of this change. A configuration file <code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code> will be shipped with the following content, leveraging the ''VendorChangeManager'' to automatically permit vendor changes for locally injected packages: <pre> version = '1.1'
[[incoming_packages]] filters = [ { filter = 'cmdline_repo', value = 'true' } ] </pre>
== Benefit to Fedora == * '''System Stability:''' Reduces the risk of accidental vendor swaps across all package operations (upgrades, downgrades, and dependency resolution).
* '''Granular Control:''' Leverages DNF5's advanced architecture (''VendorChangeManager'') to allow explicit, trusted vendor transitions while keeping the general system safe from accidental overwrites.
== Scope == * Proposal owners: ** Add <code>allow_vendor_change=False</code> to <code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code> in the <code>fedora-release-common</code> package. ** Ship a new <code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code> in the <code>fedora-release-common</code> package, with the following content: <pre> version = '1.1'
[[incoming_packages]] filters = [ { filter = 'cmdline_repo', value = 'true' } ] </pre>
* Other developers: N/A. This change is confined to the <code>fedora-release-common</code> package. No changes to packaging guidelines, RPM spec files, or build processes are required from other package maintainers.
* Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13394 #13394]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This proposal does not directly target any specific Fedora Strategy 2028 theme, but it improves the reliability of the package management foundation on which all Fedora variants build.
== Upgrade/compatibility impact == * '''Existing installations upgrading to Fedora 45:''' Will automatically inherit this safety feature via the updated dnf5 defaults, unless the user has explicitly overridden <code>allow_vendor_change = true</code> – e.g. in system configuration files in <code>/etc/dnf/libdnf5.conf.d/</code> drop-in directory or <code>/etc/dnf/dnf.conf</code>.
* '''User intervention for intentional changes:''' If a user explicitly wants to switch a package to a different <code>VENDOR</code> (and no ''VendorChangeManager'' rule applies), they will need to use the <code>--from-vendor=VENDOR</code> or <code>--setopt=allow_vendor_change=1</code> (which completely disables vendor change control for all packages, not just for the package listed in the command line) for that specific transaction.
== Early Testing (Optional) == Do you require 'QA Blueprint' support? No
== How To Test ==
=== Test Scenario A: Preventing unwanted vendor change via Upgrade ===
# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code> tag (e.g., from a Copr repository). # Enable another repository containing the same package name with a higher version/release but with a different <code>VENDOR</code> tag, ensuring no ''VendorChangeManager'' rule allows a transition between these two specific vendors. # Run <code>dnf5 upgrade PACKAGE</code>. # '''Expected result:''' DNF5 should not replace the package with the one from the new vendor. It should keep the current package and either skip the update or fail with a dependency conflict. # '''Verification of override:''' Running <code>dnf5 --setopt=allow_vendor_change=1 upgrade PACKAGE</code> should successfully allow the transaction and change the vendor.
=== Test Scenario B: Preventing unwanted vendor change via Downgrade ===
# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code> tag (e.g., from a Copr repository). # Enable another repository containing the same package name with a lower version/release but with a different <code>VENDOR</code> tag, ensuring no ''VendorChangeManager'' rule allows a transition between these two specific vendors. # Run <code>dnf5 downgrade PACKAGE</code>. # '''Expected result:''' DNF5 should not swap the package vendor to perform the downgrade. It should refuse the transaction or fail with a dependency conflict. # '''Verification of override:''' Running <code>dnf5 --setopt=allow_vendor_change=1 downgrade PACKAGE</code> should successfully allow the transaction and change the vendor.
== User Experience == * '''Users with only official Fedora repositories:''' No noticeable change. Packages should originate from the same vendor, so no vendor change conflicts should arise during updates.
* '''Users with packages from multiple sources (RPM Fusion, Copr, corporate repositories, etc.):''' DNF5 will no longer silently replace a package installed from one source with a version from a different source. If a system update or dependency resolution would result in such a replacement, DNF5 will decline the transaction and inform the user about the conflict, instead of making the change without notice.
* '''Installing a local RPM file:''' Installing a package directly from a file (e.g. <code>dnf5 install ./package.rpm</code>) will continue to work as before, without requiring any additional options.
* '''Intentional vendor switch:''' Users who deliberately want to replace a package with a version from a different source can use the new <code>--from-vendor=VENDOR</code> option to allow that specific switch for the duration of the transaction.
== Dependencies == This change requires that ''libdnf5'' with full ''VendorChangeManager'' support, the <code>allow_vendor_change</code> configuration option, and the <code>--from-vendor=</code> CLI argument is available in Fedora 45. This requirement is already satisfied: the necessary ''libdnf5'' version is available in Fedora 44 updates and will be present in Fedora 45.
== Contingency Plan == * Contingency mechanism: Revert the shipped configuration. * Contingency deadline: the beta freeze. * Blocks release? No.
== Documentation == * The <code>allow_vendor_change</code> configuration option is documented in the [https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html DNF5 Configuration Reference]. * The ''VendorChangeManager'' rule file format (used for the <code>/usr/share/dnf5/vendors.d/</code> drop-in directory) is documented in the [https://dnf5.readthedocs.io/en/latest/dnf5.conf-vendorpolicy-v1_1.5.html DNF5 Vendor Change Policy File Reference - v1.1]. * The <code>--from-vendor=</code> CLI argument is documented per individual command, for example in the [https://dnf5.readthedocs.io/en/latest/commands/install.8.html Install Command] reference.
== Release Notes == Starting with Fedora Linux 45, '''DNF5/libdnf5''' no longer automatically replaces an installed package with a version from a different vendor during updates, downgrades, or dependency resolution. If you have packages from third-party repositories (such as RPM Fusion, Copr, or corporate repositories), '''DNF5/libdnf5''' will refuse transactions that would silently switch those packages to a different vendor and will notify you of the conflict instead.
To allow a vendor change for specific packages in a given transaction, use the <code>--from-vendor=VENDOR</code> option. To disable this protection entirely for a single transaction, use <code>--setopt=allow_vendor_change=1</code>. To restore the previous behavior permanently, set <code>allow_vendor_change = true</code> in a drop-in configuration file under <code>/etc/dnf/libdnf5.conf.d/</code>.
On 30/06/2026 18:56, Aoife Moloney via devel-announce wrote:
By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
1. If a user has enabled a third-party COPR repository, then after this change they won't be able to automatically install packages from it via a simple "sudo dnf copr enable ... && sudo dnf upgrade --refresh" command, right?
2. What happens if a user installs a package from a third-party COPR repository, and then a new version appears in the official Fedora repository? Will they be permanently locked to this unsupported version, or what?
I have replied in the discussion thread https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch.... Also, I apologize for not responding here sooner; this thread somehow slipped under my radar.
If I understand you correctly, you don't have an issue with disabling vendor changes for installed packages by default. However, you are concerned that packages installed from COPR will be permanently locked to an unsupported version when a newer version appears in the Fedora repositories. You would like a specific exception for packages installed from COPR (vendor starting with "Fedora Copr") so that if a newer official version appears (vendor equal to "Fedora Project"), libdnf5 would automatically allow switching to this official version.
While libdnf5 should not have such exceptions hardcoded, it is highly configurable, and this behavior can be achieved by adding a configuration file with the following content:
=== version = '1.1'
[[incoming_vendors]] vendor = 'Fedora Project' comparator = 'EXACT'
[[outgoing_vendors]] vendor = 'Fedora Copr' comparator = 'STARTSWITH' ===
Therefore, implementing this behavior is not an issue. The only thing we need to agree on is which exceptions we want to include by default. The proposal already includes a different exception that allows packages defined directly via file path/URL to ignore the vendor change restriction.
Once upon a time, Jaroslav Rohel jrohel@redhat.com said:
If I understand you correctly, you don't have an issue with disabling vendor changes for installed packages by default. However, you are concerned that packages installed from COPR will be permanently locked to an unsupported version when a newer version appears in the Fedora repositories. You would like a specific exception for packages installed from COPR (vendor starting with "Fedora Copr") so that if a newer official version appears (vendor equal to "Fedora Project"), libdnf5 would automatically allow switching to this official version.
The same is true of packages migrating from third-party repos such as RPMFusion to Fedora, which happens from time to time.
On Mon, Jul 13, 2026 at 8:40 AM Chris Adams linux@cmadams.net wrote:
Once upon a time, Jaroslav Rohel jrohel@redhat.com said:
If I understand you correctly, you don't have an issue with disabling vendor changes for installed packages by default. However, you are concerned that packages installed from COPR will be permanently locked to an unsupported version when a newer version appears in the Fedora repositories. You would like a specific exception for packages installed from COPR (vendor starting with "Fedora Copr") so that if a newer official version appears (vendor equal to "Fedora Project"), libdnf5 would automatically allow switching to this official version.
The same is true of packages migrating from third-party repos such as RPMFusion to Fedora, which happens from time to time.
Deliberate transitions can be handled through configuration. Either they can be shipped in rpmfusion-release or fedora-repos. As for COPR, the copr DNF plugin could grow optional functionality to add a drop-in configuration file for this alongside the repo configuration. This could be twiddled server side too by COPR itself, similar to what is done with repo priorities and other features.
Does dnf5 support some sort of explicit vendor change or an automatic rollover in the case one vendor deprecates a package while another still has it?
One example that would benefit from either would have been the FFMPEG package which migrated from RPMFusion to Fedora, without the automatic vendor change users with the RPMFusion package would have been using a deprecated package without knowing.
It is also not uncommon for package maintainers to put a work-in-progress version on COPR, having to switch back and forth would be fairly tedious.
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch...
== Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
With regards, Daniel
On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch...
== Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
It is deliberately not marketed as a security feature for the reasons you are stating. Tying it to PGP signature fingerprints would be an interesting extension, but I don't think that currently exists in libsolv (we're using the libsolv feature internally).
To be honest, the main driver is for consistency and usability for Fedora with user-added third party repositories and for Fedora derivatives (like Remixes) who ship their own stuff and have their own overrides for Fedora packages. For example, Fedora Asahi Remix relies on this feature to ensure upgrades don't result in broken systems through package transitions between FAR and mainline Fedora.
I wonder if there is some mechanism to notify the user that an update with a vendor change is available that would be an upgrade to the current installed version?
Neal Becker wrote:
I wonder if there is some mechanism to notify the user that an update with a vendor change is available that would be an upgrade to the current installed version?
There will be a mechanism for this. In such cases, DNF5 will display a message about the availability of a newer version from a different vendor, likely along with a hint on how to install it. We are currently preparing this feature.
Dne 08. 07. 26 v 13:18 Neal Gompa napsal(a):
On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch... == Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
It is deliberately not marketed as a security feature for the reasons you are stating. Tying it to PGP signature fingerprints would be an interesting extension, but I don't think that currently exists in libsolv (we're using the libsolv feature internally).
To be honest, the main driver is for consistency and usability for Fedora with user-added third party repositories and for Fedora derivatives (like Remixes)
Well, why the derivatives do not change the option?
I personally quite often benefit from having multiple repositories from different vendors, using e.g. Copr to test more recent version than the official one. Therefore I prefer the current behavior.
Vít
who ship their own stuff and have their own overrides for Fedora packages. For example, Fedora Asahi Remix relies on this feature to ensure upgrades don't result in broken systems through package transitions between FAR and mainline Fedora.
On Thu, Jul 9, 2026 at 9:33 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 08. 07. 26 v 13:18 Neal Gompa napsal(a):
On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch... == Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
It is deliberately not marketed as a security feature for the reasons you are stating. Tying it to PGP signature fingerprints would be an interesting extension, but I don't think that currently exists in libsolv (we're using the libsolv feature internally).
To be honest, the main driver is for consistency and usability for Fedora with user-added third party repositories and for Fedora derivatives (like Remixes)
Well, why the derivatives do not change the option?
I personally quite often benefit from having multiple repositories from different vendors, using e.g. Copr to test more recent version than the official one. Therefore I prefer the current behavior.
You mean the behavior of randomly switching back and forth? Because if you want to lock onto a Copr, this essentially makes that work by default now.
There are people who use third party builds of stuff included in Fedora that has more functionality or different functionality for whatever reason. Not having to worry about it being randomly swapped out from underneath them is pretty useful, I think.
All this does is make it so switching providers is explicit rather than implicit.
Dne 09. 07. 26 v 16:06 Neal Gompa napsal(a):
On Thu, Jul 9, 2026 at 9:33 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 08. 07. 26 v 13:18 Neal Gompa napsal(a):
On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch... == Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
It is deliberately not marketed as a security feature for the reasons you are stating. Tying it to PGP signature fingerprints would be an interesting extension, but I don't think that currently exists in libsolv (we're using the libsolv feature internally).
To be honest, the main driver is for consistency and usability for Fedora with user-added third party repositories and for Fedora derivatives (like Remixes)
Well, why the derivatives do not change the option?
I personally quite often benefit from having multiple repositories from different vendors, using e.g. Copr to test more recent version than the official one. Therefore I prefer the current behavior.
You mean the behavior of randomly switching back and forth? Because if you want to lock onto a Copr, this essentially makes that work by default now.
No, I don't want to lock onto Copr, because quite often the Copr repository becomes stalled or is even removed once the work is moved into Fedora official repo.
There are people who use third party builds of stuff included in Fedora that has more functionality or different functionality for whatever reason. Not having to worry about it being randomly swapped out from underneath them is pretty useful, I think.
All this does is make it so switching providers is explicit rather than implicit.
I see your point. But one or the other group will be sad if this is approved. Hard to judge which group is bigger.
But shouldn't such setting be part of some repo data or something? Because I can even imagine that I would prefer to stick with some repo while from others, I just want the most recent version.
BTW with all due respect, I can't help but the VendorChangeManager seems to be quite overengineered. While it seems it could e.g. enable all Copr repositories, I can't imagine I would be able to come up with such policy.
Vít
On Thu, Jul 9, 2026 at 10:57 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 09. 07. 26 v 16:06 Neal Gompa napsal(a):
On Thu, Jul 9, 2026 at 9:33 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 08. 07. 26 v 13:18 Neal Gompa napsal(a):
On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 30, 2026 at 05:56:42PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-ch... == Detailed Description == By default, ''libdnf5'' allows packages to switch vendors if a repository provides a different version or release of a package with a different <code>VENDOR</code> tag that satisfies a transaction. While this can sometimes resolve dependencies automatically, it can lead to unexpected behavior in multi-vendor setups (e.g., mixing packages between official Fedora Project, RPM Fusion, Copr, or third-party corporate repositories).
For instance, an essential multimedia package or a proprietary driver supplied by a specific vendor could be silently overwritten or downgraded by a package from another vendor during system updates or dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's default distribution configuration for DNF5, Fedora will achieve strict vendor isolation by default. A package will only be modified if the replacement package originates from the same vendor as the currently installed package, ensuring predictable behavior across all package operations.
I see this change appears to be careful not to use to the word "security", but preventing vendor transitions is effectively acting as a security measure.
If a 3rd party repo gets compromised, it purports to prevent that repo from distributing a malicious package that "upgrades" a standard Fedora package.
I'm curious whether that is actually the case though? The change suggests this protection relies on the "VENDOR" tag in the RPM, but AFAIK nothing stops anyone from building their RPM with the "VENDOR" tag set to "Fedora Project".
Does this vendor protection only work when we have co-operating repository vendors who promise not to step on each others' "VENDOR" tags ?
It would be nice if the "VENDOR" tag was tied to the RPM signing keys, so that there is a cryptographic block on spoofing the vendor identifier.
I'm still in support of this change proposal, just wondering about the limits of the protection it offers and possibility for future improvement.
It is deliberately not marketed as a security feature for the reasons you are stating. Tying it to PGP signature fingerprints would be an interesting extension, but I don't think that currently exists in libsolv (we're using the libsolv feature internally).
To be honest, the main driver is for consistency and usability for Fedora with user-added third party repositories and for Fedora derivatives (like Remixes)
Well, why the derivatives do not change the option?
I personally quite often benefit from having multiple repositories from different vendors, using e.g. Copr to test more recent version than the official one. Therefore I prefer the current behavior.
You mean the behavior of randomly switching back and forth? Because if you want to lock onto a Copr, this essentially makes that work by default now.
No, I don't want to lock onto Copr, because quite often the Copr repository becomes stalled or is even removed once the work is moved into Fedora official repo.
There are people who use third party builds of stuff included in Fedora that has more functionality or different functionality for whatever reason. Not having to worry about it being randomly swapped out from underneath them is pretty useful, I think.
All this does is make it so switching providers is explicit rather than implicit.
I see your point. But one or the other group will be sad if this is approved. Hard to judge which group is bigger.
But shouldn't such setting be part of some repo data or something? Because I can even imagine that I would prefer to stick with some repo while from others, I just want the most recent version.
You *can* sort of finagle this with repo priorities, but it's kind of messy and when you have interdependent Copr repositories, it's really hard to manage properly.
Personally, I think the default of not automatically switching is probably closer to what most people tend to expect when using third party repositories.
BTW with all due respect, I can't help but the VendorChangeManager seems to be quite overengineered. While it seems it could e.g. enable all Copr repositories, I can't imagine I would be able to come up with such policy.
The VendorChangeManager evolved out of specific needs for Fedora Asahi Remix where we wanted a path to "unfork" packages as our code got upstreamed and shipped in mainline Fedora. I think for most cases, it does look over-engineered. But it's useful for things like FAR and the various Fedora Mobile efforts going on right now. We started using this functionality with FAR 44 so that we could smoothly unfork the mesa package, for example.
I think we'll see its functionality used more by derivatives doing stuff like that rather than the main use-case. I can also think of a few cases with RHEL and layered products where this would be useful, but they aren't too important for the Fedora context.
-- 真実はいつも一つ！/ Always, there's only one truth!
IMHO the default should be vendor change prohibition, with a dnf argument to allow explicit transitions. ie
dnf update --allow-vendor-change somepackage
(and then --disablerepo can be used for finer control of the transition if needed)
Regards,
On Thu, Jul 9, 2026 at 11:42 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote:
IMHO the default should be vendor change prohibition, with a dnf argument to allow explicit transitions. ie
dnf update --allow-vendor-change somepackage
(and then --disablerepo can be used for finer control of the transition if needed)
I prefer to not have automatic vendor change, but I'd like to be told that
a newer version is available with a different vendor in my allowed repos. Otherwise if I for example installed from copr and then forgot about it, I might never learn that a newer version is available in Fedora updates.
Neal Becker wrote:
On Thu, Jul 9, 2026 at 11:42 AM Nicolas Mailhot via devel < devel@lists.fedoraproject.org> wrote:
IMHO the default should be vendor change prohibition, with a dnf argument to allow explicit transitions. ie dnf update --allow-vendor-change somepackage (and then --disablerepo can be used for finer control of the transition if needed) I prefer to not have automatic vendor change, but I'd like to be told that a newer version is available with a different vendor in my allowed repos.
Otherwise if I for example installed from copr and then forgot about it, I might never learn that a newer version is available in Fedora updates.
We are currently working on adding a notification to DNF5 when a newer version is available from a different vendor.
-
Aoife Moloney via devel-announce -
Chris Adams -
Daniel P. Berrangé -
Jan Drögehoff -
Jaroslav Rohel -
Neal Becker -
Neal Gompa -
Nicolas Mailhot -
Vitaly Zaitsev -
Vít Ondruch