RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2070722 - SHA-1 signatures work in DEFAULT
Summary: SHA-1 signatures work in DEFAULT
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gnupg2
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stanislav Zidek
Mirek Jahoda
URL:
Whiteboard:
: 2184354 (view as bug list)
Depends On:
Blocks: 2182485
TreeView+ depends on / blocked
 
Reported: 2022-03-31 18:36 UTC by Stanislav Zidek
Modified: 2024-01-04 08:35 UTC (History)
14 users (show)

Fixed In Version: gnupg2-2.3.3-3.el9
Doc Type: Known Issue
Doc Text:
.GnuPG incorrectly allows using SHA-1 signatures even if disallowed by `crypto-policies` The GNU Privacy Guard (GnuPG) cryptographic software can create and verify signatures that use the SHA-1 algorithm regardless of the settings defined by the system-wide cryptographic policies. Consequently, you can use SHA-1 for cryptographic purposes in the `DEFAULT` cryptographic policy, which is not consistent with the system-wide deprecation of this insecure algorithm for signatures. To work around this problem, do not use GnuPG options that involve SHA-1. As a result, you will prevent GnuPG from lowering the default system security by using the insecure SHA-1 signatures.
Clone Of:
Environment:
Last Closed: 2023-05-02 15:54:34 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CRYPTO-7204 0 None None None 2022-05-11 06:44:10 UTC
Red Hat Issue Tracker RHELPLAN-117566 0 None None None 2022-03-31 18:53:48 UTC

Internal Links: 2184640 2184659

Description Stanislav Zidek 2022-03-31 18:36:54 UTC 
Description of problem:
Both signing and verification works on both keys and messages with SHA-1. This is against our effort to disable signing usage of SHA-1 in RHEL-9.

Version-Release number of selected component (if applicable):
gnupg2-2.3.3-1.el9

How reproducible:
always

Steps to Reproduce:
1. run /CoreOS/gnupg2/Sanity/sha-1

Actual results:
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Keys must not use SHA-1
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

$ name="rpmkey"
$ 
$ rlRun "$gpg --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key $name" 1-255
:: [ 18:21:27 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key rpmkey'
gpg: directory '/tmp/tmp.fingertipt/./.gnupg' created
gpg: keybox '/tmp/tmp.fingertipt/./.gnupg/pubring.kbx' created
gpg: /tmp/tmp.fingertipt/./.gnupg/trustdb.gpg: trustdb created
gpg: key 2F1A7F1ECB9B7E93 marked as ultimately trusted
gpg: directory '/tmp/tmp.fingertipt/./.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/tmp/tmp.fingertipt/./.gnupg/openpgp-revocs.d/E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93.rev'
:: [ 18:21:28 ] :: [   FAIL   ] :: Command 'gpg --homedir ./.gnupg --batch --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key rpmkey' (Expected 1-255, got 0)
$ 
$         # should work in LEGACY
$         rlRun "update-crypto-policies --set LEGACY"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set LEGACY'
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:28 ] :: [   PASS   ] :: Command 'update-crypto-policies --set LEGACY' (Expected 0, got 0)
$         rlRun "$gpg --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key $name"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key rpmkey'
gpg: A key for "rpmkey" already exists
:: [ 18:21:28 ] :: [   FAIL   ] :: Command 'gpg --homedir ./.gnupg --batch --passphrase '' --cert-digest-algo=SHA1 --quick-gen-key rpmkey' (Expected 0, got 2)
$         rlRun "update-crypto-policies --set DEFAULT"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set DEFAULT'
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:28 ] :: [   PASS   ] :: Command 'update-crypto-policies --set DEFAULT' (Expected 0, got 0)
$         rlRun "$gpg --list-keys $name"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-keys rpmkey'
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2024-03-30
pub   rsa3072 2022-03-31 [SC] [expires: 2024-03-30]
      E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93
uid           [ultimate] rpmkey
sub   rsa3072 2022-03-31 [E]

:: [ 18:21:28 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-keys rpmkey' (Expected 0, got 0)
$         rlRun "$gpg --list-secret-keys --keyid-format=0xlong $name"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-secret-keys --keyid-format=0xlong rpmkey'
sec   rsa3072/0x2F1A7F1ECB9B7E93 2022-03-31 [SC] [expires: 2024-03-30]
      E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93
uid                   [ultimate] rpmkey
ssb   rsa3072/0x9A1AEB9A1E6CC656 2022-03-31 [E]

:: [ 18:21:28 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-secret-keys --keyid-format=0xlong rpmkey' (Expected 0, got 0)
$ 
$         rlRun "$gpg -o $name.pub -a --export"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch -o rpmkey.pub -a --export'
:: [ 18:21:28 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch -o rpmkey.pub -a --export' (Expected 0, got 0)
$         rlRun -s "$gpg --list-packets $name.pub"
:: [ 18:21:28 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-packets rpmkey.pub'
# off=0 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
	version 4, algo 1, created 1648750887, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 2F1A7F1ECB9B7E93
# off=400 ctb=b4 tag=13 hlen=2 plen=6
:user ID packet: "rpmkey"
# off=408 ctb=89 tag=2 hlen=3 plen=472
:signature packet: algo 1, keyid 2F1A7F1ECB9B7E93
	version 4, created 1648750887, md5len 0, sigclass 0x13
	digest algo 2, begin of digest 47 46
	hashed subpkt 33 len 21 (issuer fpr v4 E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 07)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID 2F1A7F1ECB9B7E93)
	data: [3072 bits]
# off=883 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
	version 4, algo 1, created 1648750887, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 9A1AEB9A1E6CC656
# off=1283 ctb=89 tag=2 hlen=3 plen=438
:signature packet: algo 1, keyid 2F1A7F1ECB9B7E93
	version 4, created 1648750887, md5len 0, sigclass 0x18
	digest algo 2, begin of digest 91 c5
	hashed subpkt 33 len 21 (issuer fpr v4 E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 2F1A7F1ECB9B7E93)
	data: [3072 bits]
:: [ 18:21:29 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-packets rpmkey.pub' (Expected 0, got 0)
$         rlAssertGrep "digest algo 2," $rlRun_LOG
:: [ 18:21:29 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.zr5JTUYN' should contain 'digest algo 2,' 
$         rm -f $rlRun_LOG
$ 
$         # make sure it cannot be imported in RPM database
$         rlRun "rpm --import $name.pub" 1
:: [ 18:21:29 ] :: [  BEGIN   ] :: Running 'rpm --import rpmkey.pub'
error: rpmkey.pub: key 1 import failed.
:: [ 18:21:29 ] :: [   PASS   ] :: Command 'rpm --import rpmkey.pub' (Expected 1, got 1)
$     rlPhaseEnd
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 2s
::   Assertions: 8 good, 2 bad
::   RESULT: FAIL (Keys must not use SHA-1)

$ 
$     rlPhaseStartTest "Messages must not be signed by SHA-1"

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Messages must not be signed by SHA-1
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

$         name="messagekey"
$ 
$         rlRun "$gpg --passphrase '' --quick-gen-key $name"
:: [ 18:21:29 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --passphrase '' --quick-gen-key messagekey'
gpg: key E94A94594038AC97 marked as ultimately trusted
gpg: revocation certificate stored as '/tmp/tmp.fingertipt/./.gnupg/openpgp-revocs.d/75A3352F3EAE103AA141E266E94A94594038AC97.rev'
:: [ 18:21:29 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --passphrase '' --quick-gen-key messagekey' (Expected 0, got 0)
$         rlRun "$gpg --list-keys $name"
:: [ 18:21:29 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-keys messagekey'
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2024-03-30
pub   rsa3072 2022-03-31 [SC] [expires: 2024-03-30]
      75A3352F3EAE103AA141E266E94A94594038AC97
uid           [ultimate] messagekey
sub   rsa3072 2022-03-31 [E]

:: [ 18:21:29 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-keys messagekey' (Expected 0, got 0)
$         rlRun "$gpg --list-secret-keys --keyid-format=0xlong $name"
:: [ 18:21:29 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-secret-keys --keyid-format=0xlong messagekey'
sec   rsa3072/0xE94A94594038AC97 2022-03-31 [SC] [expires: 2024-03-30]
      75A3352F3EAE103AA141E266E94A94594038AC97
uid                   [ultimate] messagekey
ssb   rsa3072/0x087BA0C0E69165B4 2022-03-31 [E]

:: [ 18:21:30 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-secret-keys --keyid-format=0xlong messagekey' (Expected 0, got 0)
$         rlRun "$gpg -o $name.pub -a --export"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch -o messagekey.pub -a --export'
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch -o messagekey.pub -a --export' (Expected 0, got 0)
$         rlRun "$gpg --list-packets $name.pub"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-packets messagekey.pub'
# off=0 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
	version 4, algo 1, created 1648750887, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 2F1A7F1ECB9B7E93
# off=400 ctb=b4 tag=13 hlen=2 plen=6
:user ID packet: "rpmkey"
# off=408 ctb=89 tag=2 hlen=3 plen=472
:signature packet: algo 1, keyid 2F1A7F1ECB9B7E93
	version 4, created 1648750887, md5len 0, sigclass 0x13
	digest algo 2, begin of digest 47 46
	hashed subpkt 33 len 21 (issuer fpr v4 E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 07)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID 2F1A7F1ECB9B7E93)
	data: [3072 bits]
# off=883 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
	version 4, algo 1, created 1648750887, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 9A1AEB9A1E6CC656
# off=1283 ctb=89 tag=2 hlen=3 plen=438
:signature packet: algo 1, keyid 2F1A7F1ECB9B7E93
	version 4, created 1648750887, md5len 0, sigclass 0x18
	digest algo 2, begin of digest 91 c5
	hashed subpkt 33 len 21 (issuer fpr v4 E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 2F1A7F1ECB9B7E93)
	data: [3072 bits]
# off=1724 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
	version 4, algo 1, created 1648750889, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: E94A94594038AC97
# off=2124 ctb=b4 tag=13 hlen=2 plen=10
:user ID packet: "messagekey"
# off=2136 ctb=89 tag=2 hlen=3 plen=472
:signature packet: algo 1, keyid E94A94594038AC97
	version 4, created 1648750889, md5len 0, sigclass 0x13
	digest algo 8, begin of digest 57 2f
	hashed subpkt 33 len 21 (issuer fpr v4 75A3352F3EAE103AA141E266E94A94594038AC97)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 07)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID E94A94594038AC97)
	data: [3070 bits]
# off=2611 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
	version 4, algo 1, created 1648750889, expires 0
	pkey[0]: [3072 bits]
	pkey[1]: [17 bits]
	keyid: 087BA0C0E69165B4
# off=3011 ctb=89 tag=2 hlen=3 plen=438
:signature packet: algo 1, keyid E94A94594038AC97
	version 4, created 1648750889, md5len 0, sigclass 0x18
	digest algo 8, begin of digest 8c 8a
	hashed subpkt 33 len 21 (issuer fpr v4 75A3352F3EAE103AA141E266E94A94594038AC97)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID E94A94594038AC97)
	data: [3072 bits]
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-packets messagekey.pub' (Expected 0, got 0)
$ 
$         rlRun "echo 'signed text' >text"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'echo 'signed text' >text'
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'echo 'signed text' >text' (Expected 0, got 0)
$         rlRun "$gpg --armor --digest-algo SHA1 --detach-sign text" 1-255
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --armor --digest-algo SHA1 --detach-sign text'
:: [ 18:21:30 ] :: [   FAIL   ] :: Command 'gpg --homedir ./.gnupg --batch --armor --digest-algo SHA1 --detach-sign text' (Expected 1-255, got 0)
$         # should work in LEGACY
$         rlRun "update-crypto-policies --set LEGACY"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set LEGACY'
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'update-crypto-policies --set LEGACY' (Expected 0, got 0)
$         rlRun "$gpg --armor --digest-algo SHA1 --detach-sign text"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --armor --digest-algo SHA1 --detach-sign text'
gpg: signing failed: File exists
:: [ 18:21:30 ] :: [   FAIL   ] :: Command 'gpg --homedir ./.gnupg --batch --armor --digest-algo SHA1 --detach-sign text' (Expected 0, got 2)
$         rlRun "update-crypto-policies --set DEFAULT"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set DEFAULT'
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'update-crypto-policies --set DEFAULT' (Expected 0, got 0)
$         rlRun -s "$gpg --list-packets text.asc"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --list-packets text.asc'
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 2F1A7F1ECB9B7E93
	version 4, created 1648750890, md5len 0, sigclass 0x00
	digest algo 2, begin of digest 47 03
	hashed subpkt 33 len 21 (issuer fpr v4 E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93)
	hashed subpkt 2 len 4 (sig created 2022-03-31)
	subpkt 16 len 8 (issuer key ID 2F1A7F1ECB9B7E93)
	data: [3069 bits]
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --list-packets text.asc' (Expected 0, got 0)
$         rlAssertGrep "digest algo 2," $rlRun_LOG
:: [ 18:21:30 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.DLS41q31' should contain 'digest algo 2,' 
$         rm -f $rlRun_LOG
$ 
$         rlRun "$gpg --verify text.asc text" 1-255
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --verify text.asc text'
gpg: Signature made Thu 31 Mar 2022 06:21:30 PM UTC
gpg:                using RSA key E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93
gpg: Good signature from "rpmkey" [ultimate]
:: [ 18:21:30 ] :: [   FAIL   ] :: Command 'gpg --homedir ./.gnupg --batch --verify text.asc text' (Expected 1-255, got 0)
$         # should work in LEGACY
$         rlRun "update-crypto-policies --set LEGACY"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set LEGACY'
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'update-crypto-policies --set LEGACY' (Expected 0, got 0)
$         rlRun "$gpg --verify text.asc text"
:: [ 18:21:30 ] :: [  BEGIN   ] :: Running 'gpg --homedir ./.gnupg --batch --verify text.asc text'
gpg: Signature made Thu 31 Mar 2022 06:21:30 PM UTC
gpg:                using RSA key E4B87BEDF2D14B36553C50082F1A7F1ECB9B7E93
gpg: Good signature from "rpmkey" [ultimate]
:: [ 18:21:30 ] :: [   PASS   ] :: Command 'gpg --homedir ./.gnupg --batch --verify text.asc text' (Expected 0, got 0)
$         rlRun "update-crypto-policies --set DEFAULT"
:: [ 18:21:31 ] :: [  BEGIN   ] :: Running 'update-crypto-policies --set DEFAULT'
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
:: [ 18:21:31 ] :: [   PASS   ] :: Command 'update-crypto-policies --set DEFAULT' (Expected 0, got 0)
$     rlPhaseEnd
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 2s
::   Assertions: 13 good, 3 bad
::   RESULT: FAIL (Messages must not be signed by SHA-1)


Expected results:
pass
Comment 8 Jakub Jelen 2022-05-18 17:55:11 UTC 
In regards to this bug, I am wondering if we could create a crypto policy for gnupg2. We certainly do not want to do the libgcrypt as it is very low-level and no configuration file for it exists.

The gnupg now has some support for compliance options, but these are only hardcoded options and they are mostly used to put the libgcrypt to the German VS NfD mode (German alternative to FIPS mode).

The gnupg looks at files /etc/gnupg/{common,gpg,gpgsm}.conf which could be used to provide system-wide defaults for gnupg. Right now, we ship the gpgconf.conf file, which is empty:

https://koji.fedoraproject.org/koji/fileinfo?rpmID=30182198&filename=/etc/gnupg/gpgconf.conf

But it might be harder to enforce this and make it user-friendly as it is the only system-wide file without any include support.
Comment 9 Demi Marie Obenour 2022-07-06 02:45:07 UTC 
Is an out-of-tree patch for libgcrypt an option?
Comment 10 Jakub Jelen 2022-07-06 18:04:49 UTC 
(In reply to Demi Marie Obenour from comment #9)
> Is an out-of-tree patch for libgcrypt an option?

If the patch will not be acceptable upstream and still of a good quality, using downstream patch is an option, but having upstream solution would be preferred.

As mentioned in the previous comment, I started investigating reusal of some existing mechanisms, but I did not get too far to come to any final conclusion nor complete solution so far.
Comment 11 Jakub Jelen 2023-03-30 09:45:15 UTC 
I was pointed out to the `--allow-weak-key-signatures` option, which should override disablement of the weak signatures. But it turns out that this affects only key signing operations of third-party keys. It does not affect:
 * self-signing keys when new key is generated (why?)
 * message signing

Then there is an option `--allow-weak-digest-algos`, which should be used when verifying signatures. But by default, only MD5 is considered a weak digest in gnupg2 master. Adding the SHA-1 is possible on the command-line or using downstream patch.

My suggestion now would be to apply a patch like this into RHEL9 update, which would be equivalent to passing `--weak-digest=SHA1` on command line:
```
diff --git a/g10/gpg.c b/g10/gpg.c
index 84706ca6b..74946b0dd 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -2573,6 +2573,7 @@ main (int argc, char **argv)
 
     /* Set default options which require that malloc stuff is ready.  */
     additional_weak_digest ("MD5");
+    additional_weak_digest ("SHA1");
     parse_auto_key_locate (DEFAULT_AKL_LIST);
 
     argc = orig_argc;
diff --git a/g10/gpgv.c b/g10/gpgv.c
index ceded4af9..277d3c8ca 100644
--- a/g10/gpgv.c
+++ b/g10/gpgv.c
@@ -205,6 +205,7 @@ main( int argc, char **argv )
   dotlock_disable ();
   gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
   additional_weak_digest("MD5");
+  additional_weak_digest("SHA1");
   gnupg_initialize_compliance (GNUPG_MODULE_NAME_GPG);
 
   pargs.argc = &argc;
```
If somebody would need to use the SHA-1 for something, they can workaround it with `--allow-weak-digest-algos`.

But I will first check with upstream if something planned or if there is no better way. This will keep some time so this will likely be delayed.
Comment 12 Jakub Jelen 2023-03-30 10:02:45 UTC 
https://dev.gnupg.org/T6433
Comment 20 Richard W.M. Jones 2023-04-06 14:53:32 UTC 
Also breaks virt-builder:
https://bugzilla.redhat.com/show_bug.cgi?id=2184994

What is the method to upgrade existing keys?  You can't just put this change in
with no documentation about how to fix the keys.
Comment 21 Clemens Lang 2023-04-06 15:12:10 UTC 
I already posted this to tech-list, but there might be others out there affected that don't read or can't read tech-list, so here are recommended steps to change your key to use SHA-256 or newer:

You can use "gpg --list-packets publickey" to list the parts of a GPG key. Look for any mention of “digest algo 2”, which is SHA-1. Alternatively “pgpdump” from the pgpdump package decodes the digest algorithm numbers for you.

If you own the private key associated with the public key that uses SHA-1, the simplest way to make the key use a modern digest algorithm is using sq-keyring-linter [1]. Note that this only works if you have the private key in an exportable form (i.e., not inside of an HSM).

For keys in an HSM, use a modern version of GnuPG which uses SHA-256 as default, or set ‘cert-digest-algo SHA256’ (or newer) in ~/.gnupg/gpg.conf, edit the key (e.g., by modifying the expiration date, or one of the subkeys), then save the key, which should create a new binding signature. Some implementations of OpenPGP (such as sequoia, which we recently started using for RPM in Fedora) do verify that a signature was made at a point in time where the binding signature was valid in the key, so you may want to do this step under libfaketime to keep the signature time of the previous binding signature. If you don't, sequoia will consider all signatures made with this key in the past as invalid.

  [1] https://crates.io/crates/sequoia-keyring-linter
Comment 23 Tom Sweeney 2023-04-07 15:21:25 UTC 
*** Bug 2184354 has been marked as a duplicate of this bug. ***
Comment 25 Jakub Jelen 2023-05-02 15:54:34 UTC 
It looks like there is too much SHA-1 living in the OpenPGP world to be able to disable these now. Deferring to later RHEL version if possible.
Comment 26 scott willis 2023-06-05 19:26:48 UTC 
Has anyone actually tried to edit keys under libfaketime? We are not having any success with the recommended approach here. We can edit the keys to enforce SHA-256 just fine, but we cannot seem to use libfaketime to keep the binding signature time the same as the original key creation. Has anyone had any success with this?
Comment 27 Clemens Lang 2023-06-06 09:47:51 UTC 
No, I haven't tried this myself yet, mostly due to a lack of time. Writing a comprehensive guide to re-creating those signatures is still on my todo list and would include attempting that.

From a quick investigation, GnuPG gets its timestamps using the library function gunpg_get_time() defined in common/gettime.c, which calls time(NULL). However, that function also reveals code that's built into GnuPG for testing purposes, which you can probably use instead of libfaketime:

       --faked-system-time epoch
              This  option  is  only  useful  for  testing;  it  sets the system time back or forth to epoch which is the number of seconds elapsed since the year 1970.  Alternatively epoch may be given as a full ISO time string (e.g.
              "20070924T154812").

              If you suffix epoch with an exclamation mark (!), the system time will appear to be frozen at the specified time.

I.e., converting your original signature time into epoch time, and then specifying gpg --faked-system-time "${epoch}!" could be an alternative to using libfaketime at all.
Note You need to log in before you can comment on or make changes to this bug.