Fixing constant preference prompts during tests

I keep getting prompted for my algorithm preferences while running all of the git test suite:

Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: Uncompressed
     Features: MDC, Keyserver no-modify

What is the best way to prevent this from happening? I want to run the entire test suite unattended and have it complete on its own.

//tæ

Tacitus Aedifex <aedifex@sdf.org> writes:

Nobody raised this so far as far as I recall; thanks for the first one to do so, as it is a sign that you are doing something unusual (e.g. have newer or different version of GPG than most other people) and others will hit by the same symptom later when whatever thing you are using as a minority right now becomes more prevalent.

In other words, we need to have a bit more detail of your environment. I made a blind guess that the above may be coming from GnuPG, and the test framework (t/test-lib.sh, t/lib-gpg.sh, etc.) tries to run our tests in a stable environment that is not affected by real $HOME etc. owned by the user who happens to be running the tests, but it could be that your copy of GnuPG may require a bit more seeding than we do in our test framework to squelch that preference prompt.

It may not be GnuPG and something else, but I think you got the general idea.

On Wed, Sep 26, 2018 at 10:15:06AM -0700, Junio C Hamano wrote:

Indeed I am. I use Qubes OS with a split GPG setup. I have a virtual machine dedicated to handling my crypto keys and I use the qubes GPG wrapper to interact with the signing VM through the Xen hypervisor. I think the only thing that needs to change is that the tests respect gpg.program setting in .gitconfig. Signing and verifying commits and tags works perfectly but the tests don't allow me to override which program is used.

It may be a little more complicated than this because looking at the tests it seems like they set up their own dummy user with dummy keys and use gpg directly. I have gpg installed on my client VM so in theory it should work. I can't tell exctly where the prompt is coming from.

//tæ

Tacitus Aedifex <aedifex@sdf.org> writes:

Yes, that is """the test framework (t/test-lib.sh, t/lib-gpg.sh, etc.) tries to run our tests in a stable environment that is not affected by real $HOME etc. owned by the user who happens to be running the tests, but it could be that your copy of GnuPG may require a bit more seeding than we do in our test framework to squelch that preference prompt.""" part in my earlier response tried to say. 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.

On Wed, Sep 26, 2018 at 02:48:49PM -0700, Junio C Hamano wrote:

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æ

On Thu, Sep 27, 2018 at 12:42:48AM +0000, Tacitus Aedifex wrote:

I'm using GnuPG 2.2.10 from Debian unstable on my system and I don't see this issue.

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.