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
