gpgv: Help automatic reject too short keys
Testing, NormalPublic
Actions

Assigned To

None

Authored By

	svuorela
	Jan 18 2024, 9:03 AM

Description

Rephrased and forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042391

Please provide a mechanism in gpgv to either communicate back the keysize of a key or fail the validation if key less than <bits>

Apt uses gpgv to verify correct signatures on package files, but apt would like to be able to reject keys smaller than <bits> even if otherwise a valid signature.

There is at least two possible ways:

give a --min-key-size argument to gpgv and an error code is given
let gpgv communicate the keysize back somehow.

Details

External Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042391

Revisions and Commits

rG GnuPG
	rG302afcb6f6af gpg: Add option --assert-pubkey_algo.

Related Objects

Mentioned In: T7189: Release GnuPG 2.5.0
T6960: Release GnuPG 2.4.5

Event Timeline

svuorela created this task.Jan 18 2024, 9:03 AM

svuorela added a subscriber: jak.

For what it's worth when I filed the Debian bug I mistakenly believed min-rsa-key-length in gpg would do that but it only applies to de-vs compliance profile and is *silently* ignored otherwise.

I do prefer communicating the key size over status FD and then enforcing it in apt, so we can downgrade it easily per repository if specified (with a minimum option we'd need to run twice so we can issue diagnostics).

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

MMh, that is a bit bad I think in that case --min-rsa-length. Couldn't we a warning if if that feature is used? "assert-algo" sounds kind of bad for me, too. Since you should be able to use e.g. ECC, too. Also for both settings I would wish that we also think about DSA.

Angel added a subscriber: Angel.Feb 5 2024, 1:42 AM

Do note there could be subkeys as well.

The multiple key types are problematic in general, since we have values of bits in different units that are not comparable.

Say we have a RSA 2048 subkey of a DSA 1024 key. How would you report that? You would need to state the four pieces. (If at least both had been RSA, you could have picked the minimum value of bits)

We check the actual used signature and the corresponding (sub)key. Whether you trust this key is a different thing and we are not able to check that. Note that the same subkey may be used with different primary keys. The whole point of gpgv is to that you pass a list of trusted keys - actually this makes this new option superfluous but in gpg it makes sense. It was easy to add it to gpgv, though.

• werner added a commit: rG302afcb6f6af: gpg: Add option --assert-pubkey_algo..Feb 10 2024, 2:51 PM

So I cherry-picked this onto 2.4.4 and I ended up with a failing build due to failed tests (it built fine without the patch)

189 tests run, 180 succeeded, 9 failed, 0 failed expectedly, 0 succeeded unexpectedly, 0 skipped.
Failed tests: tests/openpgp/issue2346.scm tests/openpgp/encrypt.scm tests/openpgp/decrypt-session-key.scm tests/openpgp/issue2346.scm tests/openpgp/encrypt.scm tests/openpgp/decrypt-session-key.scm tests/openpgp/issue2346.scm tests/openpgp/encrypt.scm tests/openpgp/decrypt-session-key.scm

Log: https://launchpadlibrarian.net/714128234/buildlog_ubuntu-noble-amd64.gnupg2_2.4.4-2ubuntu1_BUILDING.txt.gz

The test log is a bit too noisy for me to quickly figure out where a test starts and where it ends and what the failure actually is, but maybe I'm just missing a simple patch I also need to cherry-pick, because I assume this had a successful test suite run before being committed?

There are various

Warning: Creating socket directory failed: gpgconf: socketdir is '/tmp/gpgscm-20240213T095403-run-tests-USyRzU'
gpgconf: no /run/user dir
gpgconf: using homedir as fallback
gpgconf: error creating socket directory
gpgconf: fatal error (exit status 1)

that I don't know why it would fail, it doesn't explain why.

Having looked at the build log again after applying the patch, I see the first test failing is

FAIL: <standard>tests/openpgp/decrypt-session-key.scm

it fails with:

Child 115840 returned: ((command ("/<<PKGBUILDDIR>>/build/bin/gpg" --no-permission-warning --always-trust --status-fd=1 --decrypt --show-session-key --output "/tmp/gpgscm-20240228T110902-decrypt-session-key-wOqDeO/sink" "/<<PKGBUILDDIR>>/build/../tests/openpgp/plain-1.asc")) (status 0) (stdout [GNUPG:] NODATA ABAB28A247BE2775 16 0
[GNUPG:] ALREADY_SIGNED 289B0EF1D105E124B6F626020EF77096D74C5F22 0
[GNUPG:] ALREADY_SIGNED A0FF4590BB6122EDEF6E3C542D727CC768697734 0
[GNUPG:] ALREADY_SIGNED 289B0EF1D105E124B6F626020EF77096D74C5F22 0
[GNUPG:] ALREADY_SIGNED 289B0EF1D105E124B6F626020EF77096D74C5F22 0
[GNUPG:] DECRYPTION_INFO EB467DCA4AD7676A6A62B2ABABAB28A247BE2775 289B0EF1D105E124B6F626020EF77096D74C5F22 -
[GNUPG:] END_DECRYPTION
[GNUPG:] DECRYPTION_FAILED 2 2 0
[GNUPG:] NOTATION_NAME 2:93E759AAACAE2A1A3D6C13AF185F846ACF803D684C0DB6BE
[GNUPG:] PLAINTEXT_LENGTH 62 1072838229 plain-1
[GNUPG:] KEY_NOT_CREATED 1108
[GNUPG:] MISSING_PASSPHRASE
[GNUPG:] BADMDC
[GNUPG:] BEGIN_ENCRYPTION

Note the MISSING_PASSPHRASE, despite having run

Presetting passphrases 
Executing: '/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase' '--preset' '--passphrase' 'def' '50B2D4FA4122C212611048BC5FC31BD44393626E'
Child 115719 returned: ((command ("/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase" --preset --passphrase def "50B2D4FA4122C212611048BC5FC31BD44393626E")) (status 0) (stdout ) (stderr )) 
Executing: '/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase' '--preset' '--passphrase' 'def' '7E201E28B6FEB2927B321F443205F4724EBE637E'
Child 115749 returned: ((command ("/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase" --preset --passphrase def "7E201E28B6FEB2927B321F443205F4724EBE637E")) (status 0) (stdout ) (stderr )) 
Executing: '/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase' '--preset' '--passphrase' 'abc' '76F7E2B35832976B50A27A282D9B87E44577EB66'
Child 115781 returned: ((command ("/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase" --preset --passphrase abc "76F7E2B35832976B50A27A282D9B87E44577EB66")) (status 0) (stdout ) (stderr )) 
Executing: '/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase' '--preset' '--passphrase' 'abc' 'A0747D5F9425E6664F4FFBEED20FBCA79FDED2BD'
Child 115803 returned: ((command ("/<<PKGBUILDDIR>>/build/agent/gpg-preset-passphrase" --preset --passphrase abc "A0747D5F9425E6664F4FFBEED20FBCA79FDED2BD")) (status 0) (stdout ) (stderr ))

Frankly I don't know why gpg-preset-passphrase is failing after cherry-picking the commit onto 2.4.4

So after taking this down to where it was only patching status.h and mainproc.c to add a write_status_output() I realized the whole issue is down to status-codes.h not being updated automatically if you apply a patch to status.h in a released version.

• werner mentioned this in T6960: Release GnuPG 2.4.5.Mar 7 2024, 3:23 PM

• werner moved this task from QA to gnupg-2.4.5 on the gnupg24 board.

• werner edited projects, added gnupg24 (gnupg-2.4.5); removed gnupg24.

• werner mentioned this in T7189: Release GnuPG 2.5.0.Jul 5 2024, 2:42 PM