On Thu, Jul 9, 2026 at 10:57 AM Vít Ondruch <[email protected]> wrote: > > > Dne 09. 07. 26 v 16:06 Neal Gompa napsal(a): > > 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. > > > 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! -- _______________________________________________ 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
