Page MenuHome GnuPG
Create Task
Maniphest T1109

Pinentry and cache update race
Open, LowPublic
Actions

Description

Two clients asking for the passpharse at about the same time. The second client
misses the updated cache value.

Client-1: Client-2:

enter get_pw        
if not in cache
   start pinentry
                         enter get_pw      
                         if not in cache   
                            [wait for other pinentry return]
   pinentry returns        
   put pw in cache          start pinentry
return pw                   pinentry returns
                            put pw in cache     
                         return pw

Details

Version
2

Related Objects

Event Timeline

• werner set Version to 2.Aug 20 2009, 12:09 PM
• werner added projects: gpgagent, gnupg, Bug Report.
• werner added a subscriber: • werner.
• werner set Due Date to Dec 31 2009, 1:00 AM.Sep 3 2009, 12:21 PM
• werner changed Due Date from Dec 31 2009, 1:00 AM to Dec 31 2011, 1:00 AM.Jul 1 2011, 12:30 PM
• werner mentioned this in T1190: gpg-agent asks same passphrase multiple times when subsequent requests are made before first request's passphrase is entered.Mar 30 2017, 7:12 PM
• werner added a comment.Jul 1 2011, 12:40 PM

Note: T1190 is a bug report regarding this.

• werner lowered the priority of this task from Normal to Low.Sep 9 2015, 4:09 PM
• werner removed Due Date.
neal added a project: Info Needed.Nov 4 2015, 12:17 PM
neal added a subscriber: neal.

I tried running:

  echo | gpg -s -a

in two terminal. In the first terminal, I got a pinentry prompt (I'm using
pinentry-tty) and in the second, gpg2 appeared to freeze. Once I entered my
passphrase correctly in the first terminal, the first gpg2 process split out the
signed message and less than a second later, the second did as well.

The code also suggests that this is fixed (agent/findkey.c)

      /* If the pinentry is currently in use, we wait up to 60 seconds
         for it to close and check the cache again.  This solves a common
         situation where several requests for unprotecting a key have
         been made but the user is still entering the passphrase for
         the first request.  Because all requests to agent_askpin are
         serialized they would then pop up one after the other to
         request the passphrase - despite that the user has already
         entered it and is then available in the cache.  This
         implementation is not race free but in the worst case the
         user has to enter the passphrase only once more. */

Interestingly, this comment is from 2006 (commit: df52700f), which predates this
bug report.

As such, I'm changing this bug's status to needs-eg. Perhaps Werner can shed
some more light on this issue.

• werner added a comment.Nov 5 2015, 4:24 PM

I am pretty sure that there is a race. The two sessions are not mutally locked
and thus the second client may ask for the passprase again.

  Pinentry-1 returns to Client-1
  task switch
  Client-2 now checks the cache again, does not see an update, starts Pinentry-2
  task switch
  Client-1 updates the cache

How ever it will be a rare problem and it would at best be annoying.

marcus merged a task: T1190: gpg-agent asks same passphrase multiple times when subsequent requests are made before first request's passphrase is entered.Apr 4 2017, 3:01 PM
marcus added a subscriber: bwurst.
marcus merged a task: T1254: pinentry: show only one password dialog - queue others.Jul 13 2017, 1:24 AM
marcus added a subscriber: torotil.