GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP

[Rick Rustad]

HI Robert.

So very glad you responded.

I understand what you're saying about logins and such. I'm on a local virtual machine that only I log into so I can't log in as anyone else.

We've customized an accounting program, business financial, to create a flat file during one of the processing events. This flat file is what my code is trying to encrypt and sign.

It may be possible that the accounting program is using a system account when running my custom code and thus trying to access Kleopatra as a system account. My experience with this accounting program is that it should pick up my OS login credentials and use them, however, I'll make that an assumption.

When I created and uploaded the keys I did check off for everyone, shouldn't the program see the keys if they are flagged as for everyone? At least for the imported public key.

I see a bigger issue looming. If this customization I'm working on will be used by many people and thus the encryption and signature processing will be utilized by the same many people, is there a way to override or tell the command line argument to GnuPG to not be user specific?

In one of my tests I replaced "--recipient" with "--default-recipient" but it had no affect, same error message.

Thank you.

Rick Rustad

-----Original Message-----
From: Robert J. Hansen <rjh at sixdemonbag.org> 
Sent: Tuesday, December 17, 2019 8:44 AM
To: Rick Rustad <rick.rustad at enavate.com>
Cc: gnupg-users at gnupg.org
Subject: Re: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP

On 2019-12-16 21:00, Rick Rustad wrote:
> I'm running into some difficulties trying to encrypt and sign a file 
> using gpg and Starksoft through a .Net C# API.

The good news is there's a good chance this is an easy fix.

> Might you have some suggestions?

Sure do.

> Error Msg1 with command line: C:Program 
> FilesGnuPGbingpg.exe--passphrase-fd 0 --verbose --batch --trust-model 
> always --pinentry-mode loopback --armor --recipient "XXXXXXXXX"
> --encrypt
> MESSAGE:
>  gpg: XXXXXXXXX: skipped: No public key
> gpg: [stdin]: encryption failed: No public key

What this means is really simple: GnuPG can't find the recipient's public key.

GnuPG stores keys on a per-user basis, not systemwide.  So if you imported the recipient's public key to your local keyring, but this code is running as a different user, GnuPG will look in that different user's keyring for the public key -- not yours.

You can test this out by switching over to whatever user account this is running as and running "gpg --list-key XXXXXXXX".  I strongly suspect you'll get no output, thus showing that when running as this user GnuPG has no access to the public key that's on your own user keyring.

While still logged into the different user account this is running as, import the public key into GnuPG.  Your problems should vanish.

If this still doesn't work you'll need to dive into Starksoft, as it's possible they're switching users and not telling you.

ATTENTION: This email was sent to Enavate from an external source. Please be extra vigilant when replying, opening attachments or clicking links.