Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 2182032

Summary:	rpm is less strict about signature verification when signing certificate is not preinstalled
Product:	[Fedora] Fedora	Reporter:	Zbigniew Jędrzejewski-Szmek <zbyszek>
Component:	rpm	Assignee:	Michal Domonkos <mdomonko>
Status:	CLOSED MIGRATED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	38	CC:	kparal, mdomonko, mrehak, pmatilai, zbyszek, zjedrzej
Target Milestone:	---	Keywords:	Security, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-11-29 12:56:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.