git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]

From
Tom G. Christensen <tgc@statsbiblioteket.dk>
Date
Jan 29, 2015, 17:34 UTC
Message-ID
<54CA6F3E.4060804@statsbiblioteket.dk>
In-Reply-To
<20150129154319.GA742@peff.net>
On 29/01/15 16:43, Jeff King wrote:
> Weird. The pubkeys are there in keyring.gpg; I wonder why the older
> version of gpg has trouble extracting them (and how one was _supposed_
> to export secret keys at that time).
>

Importing the unmodified keyring.gpg with 1.2.6 yields this: $ gpg --homedir "$GNUPGHOME" --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: Total number processed: 2 gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir "$GNUPGHOME" --list-keys $ gpg --homedir "$GNUPGHOME" --list-secret-keys /home/tgc/gpghome/secring.gpg ----------------------------- sec 1024D/CDDE430D 2007-06-07 C O Mitter <committer@example.com> ssb 2048g/7703B0E5 2007-06-07

sec 2048R/B7227189 2013-03-22 Eris Discordia <discord@example.net> ssb 2048R/29472784 2013-03-22 $

> So if I understand you correctly, the tests should pass with the patch
> below?
>

Yes, adding the pubkeys as a separate entity makes gpg 1.2.6 understand things fine.

gnupg 1.2.6 with the patched keyring: $ gpg --homedir "$GNUPGHOME" --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key "C O Mitter <committer@example.com>" imported gpg: key B7227189: public key "Eris Discordia <discord@example.net>" imported gpg: Total number processed: 4 gpg: imported: 2 (RSA: 1) gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir "$GNUPGHOME" --list-keys /home/tgc/gpghome/pubring.gpg ----------------------------- pub 1024D/CDDE430D 2007-06-07 C O Mitter <committer@example.com> sub 2048g/7703B0E5 2007-06-07

pub 2048R/B7227189 2013-03-22 Eris Discordia <discord@example.net> sub 2048R/29472784 2013-03-22 $

The patch should work as posted, though I have only tested the new keyring by hand as shown above.

> It feels a bit hacky, and I wish I knew more about why the current file
> doesn't work (i.e., if we did "gpg --export-secret-keys" with v1.2.6,
> would it produce different output that can be read by both versions?).
I grabbed the binary keyrings from 1e3eefb^ and pointed gpg 1.2.6 at them.

$ gpg --homedir "$GNUPGHOME" --armor --export-secret-keys CDDE430D > CDDE430D.secret.key $ gpg --homedir "$PWD/gpghome3" --import CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome3/secring.gpg' created gpg: keyring `/home/tgc/gpghome3/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir "$PWD/gpghome3" --list-keys $

No public key imported however the pubkey *was* exported to CDDE430D.secret.key

Importing that same keyfile using gnupg 1.4.5 on an RHEL5 host: $ gpg --homedir "$PWD/gpghome" --import /tmp/CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key "C O Mitter <committer@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir "/home/tgc/gpghome" --list-keys /home/tgc/gpghome/pubring.gpg ----------------------------- pub 1024D/CDDE430D 2007-06-07 uid C O Mitter <committer@example.com> sub 2048g/7703B0E5 2007-06-07 $

So gnupg 1.2.6 can export fine but cannot correctly import the same.
> Another option is to just declare that version old and broken, and skip
> the tests (either by checking its version, or just checking after we
> import the keys that we can actually _use_ them).
>

That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg.

<snip patch>
-tgc
-- 
Tom G. Christensen - Systemmedarbejder - IT-drift
Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aarhus C
Tlf: (+45) 8946 2027 - Fax: (+45) 8946 2029
CVR/SE: 10100682 - EAN: 5798000791084
Previous: Jeff KingNext: Junio C Hamano
Message 11 of 31 in “[ANNOUNCE] Git v2.3.0-rc2”
  1. Junio C HamanoJan 27, 2015
  2. Broken makefile check for curl version on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]Tom G. Christensen, Jan 29, 2015
  3. Makefile: Handle broken curl version number in version checkTom G. Christensen, Jan 30, 2015
  4. Andreas SchwabJan 30, 2015
  5. Tom G. ChristensenJan 30, 2015
  6. Kyle J. McKayJan 30, 2015
  7. Junio C HamanoJan 30, 2015
  8. All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]Tom G. Christensen, Jan 29, 2015
  9. Jeff KingJan 29, 2015
  10. Jeff KingJan 29, 2015
  11. Tom G. ChristensenJan 29, 2015
  12. Junio C HamanoJan 29, 2015
  13. Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]Tom G. Christensen, Jan 29, 2015
  14. Jeff KingJan 29, 2015
  15. Tom G. ChristensenJan 30, 2015
  16. t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'Tom G. Christensen, Jan 30, 2015
  17. brian m. carlsonJan 30, 2015
  18. Kyle J. McKayJan 31, 2015
  19. Junio C HamanoFeb 2, 2015
  20. Kyle J. McKayFeb 2, 2015
  21. Junio C HamanoFeb 2, 2015
  22. Junio C HamanoFeb 12, 2015
  23. 0/2 Getopt::Long workaround in send-emailJunio C Hamano, Feb 13, 2015
  24. 1/2 git-send-email.perl: support no- prefix with older GetOptionsJunio C Hamano, Feb 13, 2015
  25. Brandon CaseyFeb 15, 2015
  26. 2/2 SQUASH??? t9001: turn --no$option workarounds to --no-$optionJunio C Hamano, Feb 13, 2015
  27. Kyle J. McKayFeb 13, 2015
  28. brian m. carlsonFeb 13, 2015
  29. Brandon CaseyFeb 15, 2015
  30. Tom G. ChristensenFeb 16, 2015
  31. Brandon CaseyFeb 16, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.