update

1 files changed, 5 insertions, 0 deletions

diff --git a/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment b/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
index cd2103219..016ecb994 100644
--- a/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
+++ b/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
@@ -8,4 +8,9 @@ A gpg agent will cache your passphrase. It is beyond the scope of the git-annex
 
 That's all that's needed for normal git-annex use, but the assistant does seem to have a larger problem in this area, since it can need to unlock a remote's key at any time to sync files from it. Since a separate
 process is spawned for each transfer, this defeats git-annex's normal in-process caching of encryption keys of remotes. So I think it needs to unlock any encrypted special remotes at startup, or when first accessing them, and pass the cached keys to the transfer processes it spawns. This is now on my todo list.
+
+However, none of the special remotes set up by the assistant will use
+password protected gpg keys, even when it's using encryption it's using a
+non-password protected shared key. So only encrypted special remotes set up
+at the command line cause this problem.
 """]]