RPM name collisions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Few weeks ago we had an announcement of a Python supply chain hack where people supplied libraries with names matching some private library names, which took precedence and overrode those private libraries, giving the hackers control.

Now, the name collisions are built-in into RPM, because that's how updates work: the original package is in 'fedora' and the updates are in, well, 'updates'.  This is fine as long as we control all repositories, but the recent trend is to loosen up and increase the repository set: rpmfusion, ROCm, packages-microsoft-com-prod are likely to be used because they contain useful software. I am all for including them, but since we have no control over them, necessarily, maybe we should rethink the consequences for the end users.

Specifically, for example, Microsoft likes to keep multiple versions online: for instance  aadlogin has nearly 30 versions from 1.0.00485001-1 to 1.0.015280001-1. As long as this is their exclusive package, this is fine---but sometimes it gets more complicated than that. For instance, there's aspnetcore-runtime, which is in Fedora, but also has nearly 70 versions in MS repo (they cover aspnetcore-runtime versions from 2.1 to 5.0; just the 3.1 variants amount just to 18 or so packages, that intersect with Fedora ones:

...

aspnetcore-runtime-3.1.x86_64    3.1.12-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.13-2.fc34 fedora
aspnetcore-runtime-3.1.x86_64    3.1.14-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64    3.1.14-1.fc34 updates
...

These packages are actually coming from Microsoft, and the versioning seems consistent, so I guess there's nothing wrong with this setup besides a possibility for confusion as to which one is actually installed. But sometimes the versions are much more divergent:

netstandard-targeting-pack-2.1.x86_64  2.1.0-1 packages-microsoft-com-prod
netstandard-targeting-pack-2.1.x86_64  5.0.104-1.fc34 fedora
netstandard-targeting-pack-2.1.x86_64  5.0.202-1.fc34   updates

and here's a really weird one:

hello.x86_64    2.8-1        packages-microsoft-com-prod
hello.x86_64    2.10-5.fc34   fedora

Why would they put it in their repo? I don't expect any harm here, but just looking at this this made me think of the Python debacle I mentioned earlier.

Is that something we need to worry about? I couldn't think of any new rules to impose on repositories, but maybe dnf should have more explicit warnings when it sees multiple versions of the same package, or at least a way to show such versions.

As it is now, I think it just handles the most current version, but this is fragile across separately managed repositories, and doesn't easily show all the available versions---in order to collect the data I wrote a script that iterates over 'yum repolist' and disables */enables one repo at a time.




For completness, here are the remaining strange cases:

openhantek.x86_64  2.06-1.fc31    rpmfusion-nonfree
openhantek.x86_64  3.2-1.fc34     fedora

procdump.x86_64   1.1-207         packages-microsoft-com-prod
procdump.x86_64   1.1.1-3.fc34    fedora
procdump.x86_64   1.1.1-218      packages-microsoft-com-prod
procdump.x86_64   1.1.1-220      packages-microsoft-com-prod
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux