On Wed, 2021-05-05 at 07:44 +0200, Dan Čermák wrote: > przemek klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> writes: > > > 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. > > Or how about teaching dnf that only certain repositories are allowed to > be used for updates (with an allowedlist for exceptions)? Then microsoft > or any other third party repo could put hello-5000-1 into their repo and > it could never compromise your system, as dnf would not consider the 3rd > party repo a valid update repo for a base system package. > > That would require dnf to track where it got the package from though > and I am not sure if it does that at the moment? It does, but then you're just opening up a whole can of worms. And, I mean, this seems like a very narrow focus. If a third party wants to do something nefarious and can convince you to "install a repository" in some way, that means that at minimum they convinced you to drop an arbitrary file in /etc/yum.repos.d . What they probably did was convince you to install a package containing the repo definition, as that's the way most third party repos deploy. Well, that package could do *absolutely anything else at all* on your system with root privileges, because that's how packaging works. And a nefarious repo doesn't really need to use an RPM name collision to do...well...anything much, really. It can just have a perfectly correctly-named package contain whatever nefarious payload it wants. So I guess my question is: is there something specific we are preventing by worrying about package name collisions, which any person in a position to produce a package name collision could not just achieve in a dozen or more other ways? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ 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
