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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
