Am Di., 31. Okt. 2023 um 19:31 Uhr schrieb Christopher < ctubb...@fedoraproject.org>:
> On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch <vondr...@redhat.com> wrote: > > > > > > Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a): > > > Hello, > > > > > > DNF5 got a complaint > > > <https://github.com/rpm-software-management/dnf5/issues/991> that > "dnf update > > > https://..." skips verifying package signatures: > > > > > > $ sudo dnf update > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm > > > [...] > > > Warning: skipped PGP checks for 2 package(s). > > > > > > A DNF5 developer confirmed that old DNF4 does not verify signatures > too. > > > The verification happens only for packages comming from a repository. > Why DNF5 > > > looks bad is because it actually prints the warning and thus keeps the > user > > > better informed. > > > > > > The nonchecking behavior probably exists to make installing local > packages > > > easy. If DNF5 would insist on checking the signatures, Fedora users > would have > > > to pass --no-gpgchecks option to their "dnf5" commands to override the > new > > > default, or start signing their packages. As always security is not > easy. > > > > > > Because this an old behavior and some users probably depend on it, > enabling > > > the verification for all cases looks like an abrupt change. > > > > > > I would would like to hear your opinion: Should DNF5 start verifying > all > > > packages? Should DNF5 keep ignoring signatures for out-of-repository > packages? > > > Or should rather narrow the verification skip to packages from a local > file > > > system? Any other options? > > > > > > Or maybe verify what it can and report the packages which can't be > > verified? You can notice that I was actually installing singed packages. > > > > But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I > > still would swear this used to be needed, that is why I try to install > > the signed packages. > > I could have sworn the same thing. I think that it should be an error > if any package (it doesn't matter if it is local or not) cannot be > verified, unless `--nogpgcheck` is specified. This seems like the only > secure-by-default option. No RPM should be allowed to be installed if > it can't be verified, unless the user explicitly allows it. If less > secure options are provided (such as only providing a warning message > or skipping verification of local RPMs), then an option must be > provided to force the secure-behavior to prevent the installation of > any RPMs that haven't been verified (something like > `--requiregpgcheck`). But my strong preference is that it require GPG > checks by default. That is the behavior that is implied by the > existence of the `--nogpgcheck` flag and the non-existence of any > other related flags. > Note that there are few differences between local and repo files here: - A repo comes with a key specification, i.e. an expected signer; a local package does not. What signature do you expect? What is the value of "any" signature? - A package installed via a repo comes "from the internet" without your control over the exact download location; a local package has been downloaded or built specifically by you, with you in control. Therefore, it does make sense that one has its signature checked and the other hasn't. Michael
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue