The scripthighlights a failure that was introduced in rG14de7b1e5904e78fcbe413a82d0f19b750bd8830.
The failure appears to happen when:
- batch importing an Ed25519 secret key which is not cryptographically protected
- the secret key's first bit is set -- that is, the secret key is an MPI with size 256 bits.
- the signature is made in batch mode
It looks to me like the problem has to do with something about secret key storage being in "native" form, and a bad interaction with pinentry, but I don't fully understand why. Without --batch, the import wants to ask for a new passphrase on import as well, in ways that it didn't before.
Here's a run of the script.
0 $ ./signing-failure ++ mktemp -d + workdir=/home/dkg/tmp/tmp.KXfHhms78v + mkdir -p -m 0700 /home/dkg/tmp/tmp.KXfHhms78v/g + echo test + cat + gpg --homedir /home/dkg/tmp/tmp.KXfHhms78v/g --batch --allow-secret-key-import --import /home/dkg/tmp/tmp.KXfHhms78v/test.key gpg: keybox '/home/dkg/tmp/tmp.KXfHhms78v/g/pubring.kbx' created gpg: /home/dkg/tmp/tmp.KXfHhms78v/g/trustdb.gpg: trustdb created gpg: key A7D5EC0AD6ADB051: public key "test key" imported gpg: key A7D5EC0AD6ADB051: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 + gpg --homedir /home/dkg/tmp/tmp.KXfHhms78v/g --batch --local-user 'test key' --armor --detach-sign /home/dkg/tmp/tmp.KXfHhms78v/test.txt gpg: signing failed: Invalid argument gpg: signing failed: Invalid argument 2 $
The attached patchsolves the problem, but only at the cost of effectively reverting rG14de7b1e5904e78fcbe413a82d0f19b750bd8830.
This change caused breakage in debian's sbuild package's autopkgtest script in two places:
- it caused an --import to fail (because --batch was not provided)
- when --batch was provided on --import, gpg failed to make a signature with the key in question, with an error message `