Uploaded image for project: 'Funtoo Linux'
  1. Funtoo Linux
  2. FL-69

keychain does not add GPG subkey for decrypting

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      From Google Groups:

      I've some trouble adding gpg keys with keychain. I apparently need to
      add both primary key and associated subkey to gpg-agent. But using
      keychain no matter which key I try to add, it always is the one
      associated with the primary key.

      This is what I do

      $ keychain 0AA975DA
      

      Then the pinentry-curses shows

      Please enter the pass-phrase to unlock the secret key for the OpenPGP
      certificate:
      "Koen Smets <koen....@gmail.com>"
      4096-bit RSA key, ID 0AA975DA,
      created 2009-08-28
      
      $ keychain 0AA975DA
      * Known gpg key: 0AA975DA
      

      Then I encrypt a file

      $ gpg -r koen....@gmail.com -e foo.txt
      

      Now, when I want to decrypt the file:

      $ gpg -d foo.txt.gz
      

      Again, pinentry-cursus asks my passphrase. This time with another message:

      Please enter the pass-phrase to unlock the secret key for the OpenPGP
      certificate:
      "Koen Smets <koen....@gmail.com>"
      4096-bit RSA key, ID A4548D20
      created 2009-08-28 (main key ID 0AA975DA).
      

      Note the difference in keys between the two dialogs.

      If I add the subkey A4548D20, instead of the associated primary key,
      after clearing the keychain same behavior occurs.

      I tried to figure out what is happening behind the scenes by setting
      debug-level to guru and writing everything a separate log file. There I
      noticed that indeed two separate keys need to be present in cache of the
      gpg-agent:

      agent_get_cache `F254C61A4F1DC4F6AF2804C949DBF1F00AA975DA'
      agent_get_cache `5017CCEEC87D8EF28E21D6E9E84ACB2CA4548D20'
      

      Where the former is asked when I use the keychain command

      $ keychain 0AA975DA
      

      or

      $ keychain A4548D20
      

      while the latter, when I try decrypting using gpg

      $ gpg -d foo.txt.gz
      

      Note that if I try:

      $ keychain 0AA975D0 A4548D20
      

      It only asks the pass-phrase once, the other one is known (as they both
      resolve to the same hash! But for decrypting a file it needs another one...

      I think I'm missing something... So, how can I properly add my gpg key
      to the keychain, such that when decrypting a file I'm not again asked
      for my pass-phrase a second time.

        Attachments

          Activity

          Hide
          oleg Oleg Vinichenko added a comment -

          keychain can use gpg keys, as described on http://www.funtoo.org/wiki/Keychain#GPG

          Show
          oleg Oleg Vinichenko added a comment - keychain can use gpg keys, as described on http://www.funtoo.org/wiki/Keychain#GPG
          Hide
          oleg Oleg Vinichenko added a comment -

          a wiki guide confirmed as working, thx anak1n c for testing.

          Show
          oleg Oleg Vinichenko added a comment - a wiki guide confirmed as working, thx anak1n c for testing.
          Hide
          igor Clemens Kaposi added a comment -

          Sorry, it still doesn’t work for me with keychain 2.7.1. Steps to reproduce:

          export gpg_key=DEADBEEF
          eval `/usr/bin/keychain --nolock --eval $gpg_key`
          touch ~/test
          gpg -r $gpg_key -e ~/test
          rm ~/test
          gpg ~/test.gpg
          

          The final GPG command to decrypt the empty test file fires up pinentry, which asks for the passphrase for my GPG subkey.

          It doesn’t matter if I use

          keychain --dir ~/.ssh/.keychain ~/.ssh/id_rsa DEADBEEF
          source ~/.ssh/.keychain/$HOST-sh
          source ~/.ssh/.keychain/$HOST-sh-gpg
          

          instead of eval `/usr/bin/keychain --nolock --eval $gpg_key`—it works neither way. It also doesn’t help if I pass both the public key ID and the subkey ID as arguments to keychain.

          (Tested on a Gentoo box and an Arch Linux box, with identical results.)

          Show
          igor Clemens Kaposi added a comment - Sorry, it still doesn’t work for me with keychain 2.7.1. Steps to reproduce: export gpg_key=DEADBEEF eval `/usr/bin/keychain --nolock --eval $gpg_key` touch ~/test gpg -r $gpg_key -e ~/test rm ~/test gpg ~/test.gpg The final GPG command to decrypt the empty test file fires up pinentry, which asks for the passphrase for my GPG subkey. It doesn’t matter if I use keychain --dir ~/.ssh/.keychain ~/.ssh/id_rsa DEADBEEF source ~/.ssh/.keychain/$HOST-sh source ~/.ssh/.keychain/$HOST-sh-gpg instead of eval `/usr/bin/keychain --nolock --eval $gpg_key` —it works neither way. It also doesn’t help if I pass both the public key ID and the subkey ID as arguments to keychain. (Tested on a Gentoo box and an Arch Linux box, with identical results.)
          Hide
          igor Clemens Kaposi added a comment -

          It seems the issue is contained in lines 782 ff. (and also 1378 ff.):

                  # Check if this key is known to the agent.  Don't know another way...
                  if echo | env -i GPG_TTY="$GPG_TTY" PATH="$PATH" GPG_AGENT_INFO="$GPG_AGENT_INFO" \
                          gpg --no-options --use-agent --no-tty --sign --local-user "$glm_k" -o- >/dev/null 2>&1; then
          

          Even if $glm_k contains the ID of the subkey, pinentry still asks for the pubkey’s passphrase (presumably because the action is --sign and not --decrypt).

          A possible hacky and ugly workaround (as currently employed in my ~/.zshrc) would be to create a tempfile, encrypt it, and immediately decrypt it—thus triggering the passphrase dialog for the subkey.

          Show
          igor Clemens Kaposi added a comment - It seems the issue is contained in lines 782 ff. (and also 1378 ff.): # Check if this key is known to the agent. Don't know another way... if echo | env -i GPG_TTY= "$GPG_TTY" PATH= "$PATH" GPG_AGENT_INFO= "$GPG_AGENT_INFO" \ gpg --no-options --use-agent --no-tty --sign --local-user "$glm_k" -o- >/dev/ null 2>&1; then Even if $glm_k contains the ID of the subkey, pinentry still asks for the pubkey’s passphrase (presumably because the action is --sign and not --decrypt ). A possible hacky and ugly workaround (as currently employed in my ~/.zshrc ) would be to create a tempfile, encrypt it, and immediately decrypt it—thus triggering the passphrase dialog for the subkey.
          Hide
          drobbins Daniel Robbins added a comment -

          Sorry for the delay on this. I actually didn't add the gpg features to keychain, and I don't use gpg (at least not for a long time,) so I need to get back into gpg to get this fixed.

          First, I need to look into sub-keys. This link seems to have a good reference: https://alexcabal.com/creating-the-perfect-gpg-keypair/ – Can I use this to reproduce the issue?

          Show
          drobbins Daniel Robbins added a comment - Sorry for the delay on this. I actually didn't add the gpg features to keychain, and I don't use gpg (at least not for a long time,) so I need to get back into gpg to get this fixed. First, I need to look into sub-keys. This link seems to have a good reference: https://alexcabal.com/creating-the-perfect-gpg-keypair/ – Can I use this to reproduce the issue?
          Hide
          igor Clemens Kaposi added a comment -

          Works for me now with keychain 2.8.0. Thank you! =)

          Show
          igor Clemens Kaposi added a comment - Works for me now with keychain 2.8.0. Thank you! =)
          Hide
          drobbins Daniel Robbins added a comment -

          Awesome

          Show
          drobbins Daniel Robbins added a comment - Awesome

            People

            • Assignee:
              Unassigned
              Reporter:
              igor Clemens Kaposi
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: