On Thu, Jul 9, 2026 at 9:33 AM Vít Ondruch <[email protected]> wrote: > > > Dne 08. 07. 26 v 13:18 Neal Gompa napsal(a): > > On Wed, Jul 8, 2026 at 6:50 AM Daniel P. Berrangé <[email protected]> > > 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-change-by-default-system-wide/195269 > >>> == 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
