Re: DNF5: Checking signatures of packages installed out of a repository?

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

 




Dne 20. 11. 23 v 16:40 Neal Gompa napsal(a):
On Tue, Nov 14, 2023 at 5:02 PM Leon Fauster via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Am 14.11.23 um 22:04 schrieb Christopher:
On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro <mcatanzaro@xxxxxxxxxx> wrote:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
<ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.
Thing is, when manually installing RPMs that don't come from a
repository, 98% of the time they are not expected to be signed by a GPG
key that you have installed, so the check is expected to fail.
The failure indicates that the source and integrity of the RPM is
uncertain. The fact that the user is expected to make a conscious
decision to bypass it when they want to accept that risk, but to be
stopped if they don't want to accept that risk, is the whole point.
So, yes, the check is expected to fail under those circumstances.

As for how common those circumstances are, I just surveyed my Fedora
systems, and 100% of the RPMs I've manually installed, including some
pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as
my own that I've built, all are signed. In my personal experience,
it's rare to come across an unsigned RPM. You may have a different
experience, but the frequency isn't the point... the point is to
provide protection by default and user choice to override and accept
the risks. Right now, we have acceptance of risk by default instead of
protection.

GPG check is just not the right thing to do in this case.
I disagree. I think it *is* the right thing to do to check, and offer
the option to skip the check. That gives users the choice to be
insecure if they want, but leaves the default secure.

If we enable GPG checking when not appropriate,
I disagree that the failure implies that GPG checking isn't
appropriate. I think the fact that an un-bypassed check failed, in
response to an RPM from an unknown or untrusted source, is very
appropriate. The only time it would not be appropriate, in my opinion,
is if the user chose to bypass it.

***we will train users to reflexively ignore GPG errors.***
So, your position is: "don't train users to ignore GPG errors... we'll
ignore them for you" ?!?!

First, I don't agree that this will happen. I think it's more likely
that users who are lax with security will continue to be lax with
security, and users who aren't will pay attention to the failures and
use that as a signal to inform their acceptance of the risks. But
second, even if you're right, the worst case scenario here is the
scenario we already have as the default: the check being ignored by
the user is nearly the same as the check not being performed at all,
which is what's happening today. If you're concerned that GPG errors
will be ignored, I don't understand why you're not concerned with the
fact that the only reason why users aren't seeing those errors today
is because GPG checks aren't running at all! All the same security
risks are still there... including the risks for an invalid or
fraudulent signature when it is present on a local RPM, in addition to
the risks when the signature is missing... they're just being ignored
by default. You're worried about a situation where a user *might*
ignore security check errors... but I'm worried that they are
auto-ignored by the system, before the user even has a chance to take
them seriously.

(We have already trained users to approve importing new GPG keys as
long as they claim to be from Fedora, since this is required every
Fedora release. This is bad enough.)
I don't agree with that either. I verify the signatures of Fedora keys
using https://fedoraproject.org/security and the keys of other repos I
use, and other users who care about security can do the same. I think
Fedora has done as good a job as one can expect, for the most part, in
trying to provide good security to those who care. But, of course,
users have to care first and do their part as well.

GPG check makes sense when installing RPMs from a configured
repository, not when manually installing RPMs from a filesystem path or
URL.
Again, I completely disagree. The check protects against corrupt
and/or malicious software, and is one of the few steps the package
management system has to proactively prevent harm to the user's system
*before* the harm is done. Skipping these checks by default is bad for
software supply chain security, regardless of whether the supply chain
involves a repo or just an RPM. The signatures are in the RPM, and the
keys in the RPM database. The fact that it came from a repo or not is
completely irrelevant for good software supply chain security
defaults.


I completly agree with you. Just wanted to note (as mcatanzaro already
pointed at). Even when all sec-checks are enabled, the local install
will produce an error because of the missing key (when its not a package
of a configured repo). The user have to get (and import) the signing key
securely ...

A common source for such keys is

rpm -qi distribution-gpg-keys

that package includes also keys of applications (not only distribution
ones). For copr repos install distribution-gpg-keys-copr.

It is very common for RPMs to be unsigned from various vendors,
because common RPM repository hosting services do not support signed
RPMs. Notably almost everything I ever get from a packagecloud.io
repository only has metadata signing with unsigned packages. This is
also how *all* Debian repositories work. It is very rare for Debian
packages to have debsigs so that they can be independently verified.



Reading this discussion, I have opened this RFE [1] to have more granular version of --no-gpgchecks


Vít



[1] https://github.com/rpm-software-management/dnf5/issues/1027

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

--
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue

[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