# [PATCH] t: lib-gpg: flush gpg agent on startup 4 messages from 2017-07-20 to 2017-07-20. Participants: santiago@nyu.edu, Santiago Torres, Junio C Hamano. Thread: https://gitlist.dev/t/46430 ## santiago@nyu.edu, 2017-07-20 16:58 Subject: [PATCH] t: lib-gpg: flush gpg agent on startup Message-ID: <20170720165814.30037-1-santiago@nyu.edu> URL: https://gitlist.dev/e/20170720165814.30037-1-santiago%40nyu.edu ``` From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when attempting to create files if tests are run multiple times. Add a cleanup script to force flushing the gpg-agent for that GNUPGHOME (if any) before setting up the GPG relevant-environment. Helped-by: Junio C Hamano Signed-off-by: Santiago Torres --- t/lib-gpg.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index ec2aa8f68..7a6c7ee6f 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -31,6 +31,7 @@ then chmod 0700 ./gpghome && GNUPGHOME="$(pwd)/gpghome" && export GNUPGHOME && + gpgconf --kill gpg-agent 2>&1 >/dev/null gpg --homedir "${GNUPGHOME}" 2>/dev/null --import \ "$TEST_DIRECTORY"/lib-gpg/keyring.gpg && gpg --homedir "${GNUPGHOME}" 2>/dev/null --import-ownertrust \ -- 2.13.3 ``` ## Santiago Torres, 2017-07-20 17:01 Subject: Re: [PATCH] t: lib-gpg: flush gpg agent on startup Message-ID: <20170720170113.fvquowatpv4ms6if@LykOS.localdomain> URL: https://gitlist.dev/e/20170720170113.fvquowatpv4ms6if%40LykOS.localdomain In-Reply-To: <20170720165814.30037-1-santiago@nyu.edu> ``` This is the patch that stemmed from [1]. I tried to keep it simple and not noisy, alhtough it breaks the && chain, it needs to be run right before the --import command. I also decided to drop the switch chain in case that regression was to be introduced in the future in other versions (hopefully gpgconf goes nowhere by then). I was able to test this on debian oldstable/stable and arch. Cheers! -Santiago. [1] https://public-inbox.org/git/xmqqvampmnmv.fsf@gitster.mtv.corp.google.com/ On Thu, Jul 20, 2017 at 12:58:14PM -0400, santiago@nyu.edu wrote: > From: Santiago Torres > > When running gpg-relevant tests, a gpg-daemon is spawned for each > GNUPGHOME used. This daemon may stay running after the test and cache > file descriptors for the trash directories, even after the trash > directory is removed. This leads to ENOENT errors when attempting to > create files if tests are run multiple times. > > Add a cleanup script to force flushing the gpg-agent for that GNUPGHOME > (if any) before setting up the GPG relevant-environment. > > Helped-by: Junio C Hamano > Signed-off-by: Santiago Torres > --- > t/lib-gpg.sh | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh > index ec2aa8f68..7a6c7ee6f 100755 > --- a/t/lib-gpg.sh > +++ b/t/lib-gpg.sh > @@ -31,6 +31,7 @@ then > chmod 0700 ./gpghome && > GNUPGHOME="$(pwd)/gpghome" && > export GNUPGHOME && > + gpgconf --kill gpg-agent 2>&1 >/dev/null > gpg --homedir "${GNUPGHOME}" 2>/dev/null --import \ > "$TEST_DIRECTORY"/lib-gpg/keyring.gpg && > gpg --homedir "${GNUPGHOME}" 2>/dev/null --import-ownertrust \ > -- > 2.13.3 > ``` ## Junio C Hamano, 2017-07-20 20:00 Subject: Re: [PATCH] t: lib-gpg: flush gpg agent on startup Message-ID: URL: https://gitlist.dev/e/xmqq379qlvzi.fsf%40gitster.mtv.corp.google.com In-Reply-To: <20170720170113.fvquowatpv4ms6if@LykOS.localdomain> ``` Santiago Torres writes: > This is the patch that stemmed from [1]. > > I tried to keep it simple and not noisy, alhtough it breaks the && > chain, it needs to be run right before the --import command. I also > decided to drop the switch chain in case that regression was to be > introduced in the future in other versions (hopefully gpgconf goes > nowhere by then). I'm inclined to do ... export GNUPGHOME && ( gpgconf --kill gpg-agent 2>&1 >/dev/null || : ) && gpg --homedir ... --import ... Imagine "chmod 0777 ./gpghome" failed and what happens. We skip the part that exports GNUPGHOME and attempts to kill gpg-agent as if nothing bad happened, and then we try to "--import". At that point we do not know what value GNUPGHOME has---are we clobbering the real keychain the user who runs the test has? With that "run it but ignore the outcome even if we failed to.", we do not have to worry about any of that ;-) > > I was able to test this on debian oldstable/stable and arch. > > Cheers! > -Santiago. > > [1] https://public-inbox.org/git/xmqqvampmnmv.fsf@gitster.mtv.corp.google.com/ > > On Thu, Jul 20, 2017 at 12:58:14PM -0400, santiago@nyu.edu wrote: >> From: Santiago Torres >> >> When running gpg-relevant tests, a gpg-daemon is spawned for each >> GNUPGHOME used. This daemon may stay running after the test and cache >> file descriptors for the trash directories, even after the trash >> directory is removed. This leads to ENOENT errors when attempting to >> create files if tests are run multiple times. >> >> Add a cleanup script to force flushing the gpg-agent for that GNUPGHOME >> (if any) before setting up the GPG relevant-environment. >> >> Helped-by: Junio C Hamano >> Signed-off-by: Santiago Torres >> --- >> t/lib-gpg.sh | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh >> index ec2aa8f68..7a6c7ee6f 100755 >> --- a/t/lib-gpg.sh >> +++ b/t/lib-gpg.sh >> @@ -31,6 +31,7 @@ then >> chmod 0700 ./gpghome && >> GNUPGHOME="$(pwd)/gpghome" && >> export GNUPGHOME && >> + gpgconf --kill gpg-agent 2>&1 >/dev/null >> gpg --homedir "${GNUPGHOME}" 2>/dev/null --import \ >> "$TEST_DIRECTORY"/lib-gpg/keyring.gpg && >> gpg --homedir "${GNUPGHOME}" 2>/dev/null --import-ownertrust \ >> -- >> 2.13.3 >> ``` ## Santiago Torres, 2017-07-20 20:25 Subject: Re: [PATCH] t: lib-gpg: flush gpg agent on startup Message-ID: <20170720202543.qw7wbrz5nhvvqt47@LykOS.localdomain> URL: https://gitlist.dev/e/20170720202543.qw7wbrz5nhvvqt47%40LykOS.localdomain In-Reply-To: ``` > With that "run it but ignore the outcome even if we failed to.", we > do not have to worry about any of that ;-) Oh right! thanks for the suggestion! Let me re-roll... Thanks, -Santiago. ```