Bug 1813244 - gpgkey_dns_verification=True does not handle
Summary: gpgkey_dns_verification=True does not handle
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-13 11:14 UTC by Petr Menšík
Modified: 2020-05-11 12:45 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-11 12:45:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Petr Menšík 2020-03-13 11:14:00 UTC
Description of problem:
When I turn gpgkey_dns_verification=True in /etc/dnf/dnf.conf, dnf starts emitting annoying errors when I have enabled copr repository with @ in its name.


Version-Release number of selected component (if applicable):
dnf-4.2.18-1.fc30.noarch
copr-cli-1.85-1.fc30.noarch


How reproducible:
always

Steps to Reproduce:
1. dnf copr enable @dnsoarc/dnscap
2. echo gpgkey_dns_verification=True >> /etc/dnf/dnf.conf
3. dnf list dnf

Actual results:
DNSSEC extension: Testing already imported keys for their validity.
Email address should contain exactly one '@' sign.
Exception raised in DNSSEC extension: email=@dnsoarc#drool.org, exception=<DnssecError, value='Email address should contain exactly one '@' sign.'>
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/dnf/dnssec.py", line 287, in check_imported_keys_validity
    result = DNSSECKeyVerification.verify(key)
  File "/usr/lib/python3.7/site-packages/dnf/dnssec.py", line 227, in verify
    result = DNSSECKeyVerification._cache_miss(input_key)
  File "/usr/lib/python3.7/site-packages/dnf/dnssec.py", line 186, in _cache_miss
    status, result = ctx.resolve(email2location(input_key.email),
  File "/usr/lib/python3.7/site-packages/dnf/dnssec.py", line 63, in email2location
    raise DnssecError(msg)
dnf.dnssec.DnssecError: Email address should contain exactly one '@' sign.
Email address should contain exactly one '@' sign.
...

Expected results:
No error or warning

Additional info:
It might be changed by way copr handles it. Not sure where it is wrong.
It might help handling copr groups the same way as dnf copr list show them. Expanding @ to group_:

copr.fedorainfracloud.org/group_dnsoarc/dnscap

Comment 1 Marek Blaha 2020-03-25 07:26:46 UTC
The problem here is that User ID field of copr gpg key is malformed:

$ wget https://download.copr.fedorainfracloud.org/results/@dnsoarc/dnscap/pubkey.gpg
$ gpg2 --show-keys pubkey.gpg 
pub   rsa2048 2017-05-29 [SCEA] [expires: 2022-05-28]
      153A22B65DBD3E8B8F84D73FBAC9B3047ED8CB60
uid                      @dnsoarc_dnscap (None) <@dnsoarc#dnscap.org>

The uid field is supposed to contain name and email address associated with the key certificate. But the email clearly is not valid.

The fix (I suppose) must be in both dnf and copr components. Copr should generate valid email into uid gpg key field and dnf should somehow cope with already released keys.
@praiskup, am I right?

Comment 2 Pavel Raiskup 2020-03-25 08:32:04 UTC
I agree: https://pagure.io/copr/copr/issue/1320

Comment 3 Marek Blaha 2020-04-03 08:00:35 UTC
PR https://github.com/rpm-software-management/dnf/pull/1613 turns those ugly exception-like errors to more readable one-line warnings.

Comment 4 Ben Cotton 2020-04-30 20:12:49 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


Note You need to log in before you can comment on or make changes to this bug.