Page MenuHome GnuPG

gpgv: Help automatic reject too short keys
Testing, NormalPublic

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.

Revisions and Commits

Event Timeline

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).

werner added a subscriber: werner.

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.

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.

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)

werner changed the task status from Open to Testing.Sat, Feb 10, 2:31 PM
werner moved this task from Backlog to QA on the gnupg24 board.

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.

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.