mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

reproduced, some analysis of a gpg bug

Browse source 
This commit was sponsored by Graham Spencer on Patreon.
This commit is contained in:
Joey Hess 2021-04-27 16:31:37 -04:00
parent c7a3404b20
commit 42cacb4099
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 53 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

53
doc/bugs/fsck_of_encrypted_remote_fails_w__47___multiple_jobs/comment_2_4f9e1debcd070da2fa70d91415d000bb._comment Normal file
View file

@ -0,0 +1,53 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2021-04-27T19:25:49Z"
content="""
I was able to reproduce this as follows:
git annex initremote dr type=directory directory=d encryption=hybrid chunk=1MB keyid=(my gpg key id)
Copy 8 different 50 mb files to the remote, then git-annex fsck --from dr -J8
Happens intermittently, I saw it twice out of the first several runs,
but have been having difficulty getting it to happen any more now.
fsck 50mb2
fsck 50mb6 (user error (gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)) failed
Hard to know why gpg is failing since it does not output any error message.
I tried enabling gpg's debugging, and found this in its debug output:
gpg: DBG: chan_5 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Joey+Hess+<joeyh@joeyh.name>%22%0A4096-
gpg: DBG: chan_5 <- OK^M
gpg: DBG: chan_5 -> PKDECRYPT^M
gpg: DBG: chan_5 <- S INQUIRE_MAXLEN 4096^M
gpg: DBG: chan_5 <- INQUIRE CIPHERTEXT^M
gpg: DBG: chan_5 -> (omitted out of fear some bytes are key material -- JEH)^M
gpg: DBG: chan_5 -> END^M
gpg: DBG: chan_5 <- ERR 16810070 Cannot allocate memory <gcrypt>
...
gpg: decryption failed: No secret key
Seems pretty likely this is really a gpg bug. Gpg should be able to decrypt
two things concurrently, and generally can without failing. This seemed to
occur when gpg was talking to gpg-agent to access the user's secret key, so
a concurrency bug in the gpg-agent interface seems likely.
Aha, here's a post to the gpg list about what looks like the same bug:
<https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html>
<https://dev.gnupg.org/T3027> this bug claims it was fixed in libgcrypt 1.7.7,
but my gpg uses 1.8.7. From the bug, I'm somewhat doubtful they really fixed it.
The lack of --batch in the gpg command line makes me think that the thing
gpg is decrypting there is not the content of a file, but the hybrid encryption
cipher from the git-annex branch. (Also IIRC it failed pretty early on.)
Normally the cipher only gets decrypted once and then cached
in memory, but there is a race possible that could decrypt it concurrently.
Not usually a problem, although I suppose it could also result in a double
password prompt when not using the gpg agent.
If this is a gpg bug, fixing that race in git-annex would mostly
avoid it. Concurrent git-annex processes might still trip over such a gpg bug,
but so could any concurrent processes.
"""]]