On Thu, Sep 27, 2018 at 12:42:48AM +0000, Tacitus Aedifex wrote: > 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 using GnuPG 2.2.10 from Debian unstable on my system and I don't see this issue. > 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. It might be worth checking to see if you have a gpg binary or script in your PATH that isn't the one you expect. That's broken things for me in the past. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
