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

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

 



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.


-- 
真実はいつも一つ!/ Always, there's only one truth!
--
_______________________________________________
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