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
