Signing-only subkeys fail to import

Behaviour

It appears that the action fails to accept signing-only subkeys when attempting to import the key.

Steps to reproduce this issue

1. Generate secret subkey with only signing capability
2. Export signing subkey to Actions Secret
3. Configure action as documented in readme

Expected behaviour

I’d expect the key to be registered successfully such that commit and tag signing works as usual.

Since the private key needs to be stored within Actions’ Secrets, it is beneficial to limit the exposed surface area of the key. For that reason, I only want the signing subkey to be stored as the secret, not the entire master secret key. (That way revocation is straightforward, in the event the key is compromised.)

Demonstration of local commit sign with signing-subkey only:

$ export GNUPGHOME=/var/folders/g5/hjyp2_y91ggcbxmqnrxs54dh0000gn/T/tmp.bcUU6uhH
$ gpg -K
$ gpg --import sign.gpg 
gpg: key 249FB5A789A6EF28: public key "Nodenv Bot (github) <[e-mail]>" imported
gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status
gpg: key 249FB5A789A6EF28: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
$ gpg -K
/var/folders/g5/hjyp2_y91ggcbxmqnrxs54dh0000gn/T/tmp.uTi7eG3E/pubring.kbx
-------------------------------------------------------------------------
sec#  rsa4096 2020-09-01 [C]
      EC4A05892FB2603243F5031D249FB5A789A6EF28
uid           [ unknown] Nodenv Bot (github) <[e-mail]>
uid           [ unknown] Nodenv Bot <[e-mail]>
ssb   rsa4096 2020-09-01 [S]
$ git config user.name nodenv-bot
$ git config user.email [e-mail]
$ git config user.signingkey 91F91D7F54BA3485
$ git ci -S --allow-empty -m testing
[bot-sign eea63992] testing
$ git show --show-signature
gpg: Signature made Tue Sep  1 20:10:08 2020 EDT
gpg:                using RSA key CEA5F06CC5C89B801954C4B291F91D7F54BA3485
gpg: Good signature from “Nodenv Bot (github) [e-mail]” [unknown]
gpg:                 aka “Nodenv Bot [e-mail]” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EC4A 0589 2FB2 6032 43F5  031D 249F B5A7 89A6 EF28
Subkey fingerprint: CEA5 F06C C5C8 9B80 1954  C4B2 91F9 1D7F 54BA 3485

Actual behaviour

When the import-gpg action runs, it generates an error:

Run crazy-max/ghaction-import-gpg@v2
  with:
    git_user_signingkey: true
    git_commit_gpgsign: true
    git_tag_gpgsign: true
    git_push_gpgsign: false
    workdir: .
  env:
    GPG_PRIVATE_KEY: ***
  
📣 GnuPG info
Version    : 2.2.4 (libgcrypt 1.8.1)
Libdir     : /usr/lib/x86_64-linux-gnu/gnupg
Libexecdir : /usr/lib/gnupg
Datadir    : /usr/share/gnupg
Homedir    : /home/runner/.gnupg
🔮 Checking GPG private key
##[error]Could not find valid encryption key packet in key 249fb5a789a6ef28

Configuration

• Repository URL (if public): https://github.com/nodenv/node-build
• Build URL (if public): https://github.com/nodenv/node-build/runs/1058938254?check_suite_focus=true

name: Test Signing
on:
  push:

jobs:
  bump:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: bot-sign
          fetch-depth: 0
          token: ${{ secrets.BOT_TOKEN }}

      - uses: crazy-max/ghaction-import-gpg@v2
        with:
          git_user_signingkey: true
          git_commit_gpgsign: true
          git_tag_gpgsign: true
        env:
          GPG_PRIVATE_KEY: ${{ secrets.BOT_GPG_KEY }}

      - run: git commit --allow-empty -m testing
        env:
          GIT_AUTHOR_NAME: 'nodenv bot'
          GIT_AUTHOR_EMAIL: '[e-mail]'
          GIT_COMMITTER_NAME: 'nodenv bot'
          GIT_COMMITTER_EMAIL: '[e-mail]'

      - run: git push

Logs

log.txt

[alekseibevzenko]

@crazy-max Hi. I have tried to use crazy-max/ghaction-import-gpg@subkey and it works. Previous version v4 was failed with ##[error]Could not find valid encryption key packet in key

[jasonkarns]

I’ve confirmed that using a Sign+Encrypt subkey works as expected, so that’s at least a workaround. (It works in my particular case… however, there are other scenarios where one can not add an additional encryption subkey because it’s generally expected that there be only a single encrypting subkey.)

Regardless, there is a slight bug (minor annoyance, really) when using only a subkey: this action reports a warning during workflow cleanup that the secret key is missing. This annotation is displayed on the workflow summary, as well as in detail within the workflow log output.

gpg: key "EC4A05892FB2603243F5031D249FB5A789A6EF28" not found gpg: EC4A05892FB2603243F5031D249FB5A789A6EF28: delete key failed: Not found

My assumption is that this action is attempting to delete the secret key that was added. However, if the secret key contains only a subkey, then the deletion fails.