Hello all, On Tuesday, November 14, 2023 8:16:39 AM EST Christopher wrote: > On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek <jmracek@xxxxxxxxxx> > wrote: > > > > I believe that one of the strong complains was related to not signed > > packages. The use case is that when I build RPMs locally and then I > > install them (see bellow). > > > > dnf install *.rpm --setopt=localpkg_gpgcheck=true > > ... > > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed > > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not > > signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is > > not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm > > is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is > > not signed Error: GPG check FAILED > > > 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. It's not just for the sake of security, there are actual security requirements that are specified around this for all distributions - no matter what the package manager is. https://commoncriteria.github.io/pp/operatingsystem/operatingsystem-release.html#FPT_TUD_EXT.1.1 There are 2 requirements, one on the metadata that dnf uses to decide if an update is available. The metadata must be signed and tested. Pass or fail needs to have an audit event that describes what was being done, what failed and if any checks are being overridden/bypassed. The second requirements is on the update installation. It also requires auditing that describes what was being done, if the update was successful, what about it failed, and if any checks were being bypassed. librpm has a module that can be installed that provides some of this auditing. But if dnf does it's own checks on metadata or the rpm before it passes it on to librpm, then it has to do the auditing itself. I would recommend making it an optional module so that people not wanting auditing are not impacted by any slow down during upgrades. But the fact that it requires auditing means there are actual security expectations that need to be factored in - such as secure by default. If the audit trail shows that the rpms are passing gpg check, but it's not being enforced, that will get the attention of the security team. And while we are talking update security, minimum hash sizes since last year are SHA384 and signatures being RSA 3072 and higher (this includes secure boot). There is also an expectation of moving away from RSA to quantum resistant algorithms in the next couple years. (This also means secure boot, too.) -Steve _______________________________________________ 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
