This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Github .
Bug 2182032 - rpm is less strict about signature verification when signing certificate is not preinstalled
Summary: rpm is less strict about signature verification when signing certificate is n...
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Domonkos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-27 11:01 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2023-11-29 12:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-29 12:56:15 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github   rpm-software-management rpm issues 1573 0 None open RFE: Enforce GPG signatures by default 2023-11-29 12:56:15 UTC
Red Hat Bugzilla 2170878 0 unspecified CLOSED Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed 2023-10-06 18:41:12 UTC

Description Zbigniew Jędrzejewski-Szmek 2023-03-27 11:01:02 UTC 
This is one facet spun out of https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c114:

$ podman run -it fedora:38
# dnf --setopt=install_weak_deps=0 upgrade -y
# curl -O https://download.anydesk.com/linux/anydesk-6.1.1-1.el7.x86_64.rpm
# sha1sum anydesk-6.1.1-1.el7.x86_64.rpm
92f3e3a50c497fa967874fd69aeda140266151e9  anydesk-6.1.1-1.el7.x86_64.rpm
# dnf --setopt=install_weak_deps=0 install ./anydesk-6.1.1-1.el7.x86_64.rpm -y
(works)
# dnf --setopt=install_weak_deps=0 --setopt=clean_requirements_on_remove=0 remove anydesk -y
(works)
# rpm --import 'https://keys.anydesk.com/repos/RPM-GPG-KEY'
# dnf --setopt=install_weak_deps=0 install ./anydesk-6.1.1-1.el7.x86_64.rpm 
...
Error: Transaction test error:
  package anydesk-6.1.1-1.el7.x86_64 does not verify: Header V3 RSA/SHA1 Signature, key ID cdffde29: BAD

As you can see, the package is "fine" in the the first attempt, and "bad" in the second attempt. It seems that the signature verification is only partial.

This has been already made public, and also I don't think it's terribly important, but I'm marking this as security because it's harder to go from unmarked to marked than the other way around. I have no problem with making it public.

rpm-4.18.1-1.fc38.x86_64
rpm-sequoia-1.3.0-1.fc38.x86_64
dnf-4.14.0-2.fc38.noarch
Comment 1 Zbigniew Jędrzejewski-Szmek 2023-03-27 11:08:45 UTC 
Oh, this can be made even simpler:

# rpm -q anydesk
anydesk-6.1.1-1.el7.x86_64
# curl -O 'https://keys.anydesk.com/repos/RPM-GPG-KEY'
# sha1sum RPM-GPG-KEY 
679867bb8d96dfdf5b972f92adf3636a40277dd2  RPM-GPG-KEY
# rpm --import ./RPM-GPG-KEY
rpm -q anydesk
error: rpmdbNextIterator: skipping h#     224 
Header V3 RSA/SHA1 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
package anydesk is not installed
# rpm -e gpg-pubkey-cdffde29
# rpm -q anydesk
anydesk-6.1.1-1.el7.x86_64
Comment 2 Zbigniew Jędrzejewski-Szmek 2023-03-31 13:34:35 UTC 
Hmm, I assumed that Panu and other maintainers have access to this bug because
packaging-team-maint is the Assignee.
Comment 3 Panu Matilainen 2023-04-03 05:55:11 UTC 
The access story is a bit hysterical, we can see the notification emails from such bugs but not the bug itself.

Anyway, this (also hysterical) behavior is as old as rpm itself. No sensical signature behavior is possible as long as unsigned packages are considered acceptable, so the only way to get a sane behavior out of this all is to make signatures mandatory with "%_pkgverify_level signature" (or "all"). That of course breaks all the workflows with local builds expected to be installable without signing.

It's something Fedora could of could experiment with of course. I suspect there would be wide breakage starting with mock/koji, requiring overrides to that config.
Comment 4 Zbigniew Jędrzejewski-Szmek 2023-04-03 08:24:48 UTC 
Thanks. This explains how we got into this situation, but I have to say the end result doesn't "feel" right.

Essentially, I would really expect that if I call 'dnf install https://some.url/something.rpm',
the signature is verified correctly or I get asked. This expectation is also built on
expected consistency: I get asked every half year if I want to accept new keys for F<n+1>,
and rpm does various checks of signatures, etc, and periodically things that Fedora distributes
do not pass this verification. This all builds expectation that stuff is being checked. If
then other operation which is _much_ more risky performs no checking *whatsoever*, no warnings
are emitted, no questions asked, this seems backwards.
Comment 5 Panu Matilainen 2023-04-03 08:46:24 UTC 
Yes, it's totally backwards and broken of course.
Comment 6 Zbigniew Jędrzejewski-Szmek 2023-04-14 11:27:33 UTC 
It seems that any solution would require bigger changes and possibly some reduction in user convenience.
I think it'd be worth discussing this more widely.

Anyone opposed to dropping the "security" label and making this public?
Comment 7 Panu Matilainen 2023-04-14 12:25:40 UTC 
Feel free to drop the security label, this isn't your average security bug, just weird but expected semantics.

I think it'd be awesome if Fedora wanted to explore making signatures mandatory by default on rpm level (supported since 4.14.2, see comment #3), it's just something I'm not eager to push by myself. People tend to have their annual quota of rpm changes full as it is :D
Comment 8 Zbigniew Jędrzejewski-Szmek 2023-04-18 10:21:35 UTC 
Can somebody unembargo this? There is no embargo but it prevents the bug from being made public.
Comment 9 Zbigniew Jędrzejewski-Szmek 2023-04-27 13:52:07 UTC 
Please unembargo this to make it public.
Note You need to log in before you can comment on or make changes to this bug.