On Wed, Sep 26, 2018 at 02:48:49PM -0700, Junio C Hamano wrote:
We do not want your choice of gpg.program or what kind of
trust you have personally recorded in your ~/.gnupg/ affect how gpg
invoked inside our tests work.
This makes sense to me now. I get what you are saying. The gpg binary installed
on my system is fairly new:
gpg --version
gpg (GnuPG) 2.2.8
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/user/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed
I'm not sure if that has anything to do with it. I'm going to have to
investigate further to figure out what is being executed and with what
parameters that leads to the prerefences prompt. While working with GPG on
another project I noticed that GPG doesn't like to work with keyrings other
than the default ones. I tried a bunch of different combinations of
--no-default-keyrings, --homedir, --default-key, etc to try to get GPG to never
touch ~/.gnupg and I couldn't figure it out. It would always re-create ~/.gnupg
and default keyrings and even read gpg.conf when explicitly told not to. I
suspect that is what is going on here.
//tæ
