Package: sbuild Version: 0.83.0 Control: affects -1 + gpg-agent Control: tags -1 + patch
When trying to upgrade to gnupg2 from version 2.2.27-1 to version 2.2.34-1, we see a failure in the unshare-qemuwrapper test: https://ci.debian.net/data/autopkgtest/testing/amd64/s/sbuild/21152998/log.gz + ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i /tmp/autopkgtest-lxc.29hmt_yk/downtmp/autopkgtest_tmp/id_rsa -T -p 10022 root@localhost env --chdir=/build/ AUTOPKGTEST_TMP=/tmp runuser -u user -- ./debian/tests/unshare Warning: Permanently added '[localhost]:10022' (ED25519) to the list of known hosts. gpg: keybox '/tmp/gpghome/pubring.kbx' created gpg: /tmp/gpghome/trustdb.gpg: trustdb created gpg: key F08FF84541F5A0C0: public key "sbuild fake uploader <fake-uploa...@debian.org>" imported gpg: key F08FF84541F5A0C0/F08FF84541F5A0C0: error sending to agent: Invalid argument gpg: key F08FF84541F5A0C0/A4179B1DD69E01DD: error sending to agent: Invalid argument gpg: key F08FF84541F5A0C0: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 I traced this error down to the use of "gpg --allow-secret-key-import --import" in the unshare script. GnuPG upstream has always maintained that use of gpg in scripts requires use of the --batch directive, which avoids the error. Why this error response was introduced in the change from GnuPG 2.2.27 to 2.2.34, i don't yet fully understand, but using --batch does avoid the problem. The attached patch should hopefully make the sbuild autopkgtest succeed with either version of GnuPG2. thanks for maintaining sbuild in debian! --dkg
From 4bdf145dd92df9db01fa38e1ab33cf1c36926ce9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <d...@fifthhorseman.net>
Date: Mon, 25 Apr 2022 12:30:11 -0400
Subject: [PATCH] Use --batch with gpg when importing secret key
The use of gpg here is automated, and should not trigger a prompt to
the user. GnuPG upstream recommends always using --batch in contexts
like this.
With GnuPG 2.2.34, the import actually fails, with gpg-agent logging
the following failures:
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument <gcrypt>
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument <gcrypt>
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+<fake-uploa...@debian.org>%22%0A255-bit+EDDSA+key,+ID+A4179B1DD69E01DD,%
0Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument <gcrypt>
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument <gcrypt>
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+<fake-uploa...@debian.org>%22%0A255-bit+ECDH+key,+ID+52C3581ED0C37392,%0
Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK
Using --batch here changes the IMPORT_KEY assuan directive such that
it includes an --unattended flag, which bypasses the failures we're
seeing on upgrading GnuPG in debian unstable.
Having to perform this workaround is unfortunate. A better approach
would be to rewrite sbuild's tooling to use OpenPGP utilities designed
for operation in a script, but doing so is a larger and more intrusive
patch.
---
debian/tests/unshare | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tests/unshare b/debian/tests/unshare
index aa23bb08..272330f5 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -101,7 +101,7 @@ verify() {
# FIXME: generate a key without expiry date
-cat << END | gpg --allow-secret-key-import --import -
+cat << END | gpg --batch --allow-secret-key-import --import -
-----BEGIN PGP PRIVATE KEY BLOCK-----
xVgEYA6+IBYJKwYBBAHaRw8BAQdAM1MKmD3Qm9XwkCv40xOUt1KTLL3nQ2NYfl6B
--
2.35.1
signature.asc
Description: PGP signature
