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

Reply via email to