gnu gpg not defaulting to only key on keyring

that's your pubring. do you have the secring too?

I'm not sure how to list or import to the secret ring.

Normally I would recommend the use of a gui tool (such as WinPT or GPA - fuller list here) but you can use the command line too.

the command line option is (logically enough)

--list-secret-keys

but if you don't have it, perhaps signing isn't what you wanted to do?

you can encrypt without signing:

\\eshare\shared\AppDev\Production\executable\GnuPG\gpg --passphrase password -e -r firstlast@email.org "\\eshare\shared\appdev\test\gnutest\R_Test\prereg.txt"

Thanks for the response.

This is for a package I have running with vendor specifications.  It must be signed and to my knowledge I can't do it automatically via a package without using the command prompt.

My problem appears to be I do not know how to import a secret key so that it is accessible under an account such as sql agent.

ok, you can import secret keys easily - the command is:

gpg --allow-secret-key-import --import <keyfile>

where <keyfile> is usually something ending in .asc
it may be the keyfile you have already has the secret key in it - without --allow-secret-key-import they will be ignored.

I ran the command and got the following response:

D:\AppDev\Sourcecode\Keys for Chase>gpg --allow-secret-key-import --import PGPPub.key
gpg: key EECBBF31: "John Doe (ELockbox) <jdoe@bis.org>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

gpg --list-secret-keys

is blank

when I attempt to run this:
\\bis\shared\AppDev\Production\executable\GnuPG\gpg --passphrase password -e --sign "\\bis\shared\appdev\test\gnutest\R_Test\prereg.txt"

still getting:

gpg: no default secret key: secret key not available
gpg: \\bis\shared\appdev\test\gnutest\R_Test\prereg.txt: sign+encrypt failed
: secret key not available

then that file doesn't have the secret key in it. being called PGPPub.key might be a bit of a clue there, do you have a PGPSec.key? :)

We have other users trouble shooting the same issue I am, they are able to import the same key as a secret key, where as I am not.  I am wondering if importing it as a public key blocks me from also using it as a secret key.  Is there a way to remove it from the other keyring and try again as the secret key import?

You were totally right, our users were just confused on which key.

So my problem seems to be solved using the points in this discussion.  By running the import key step in a package it allows sql agent to have the secret key on its keyring.

Thanks for everything.