Validating a key in GNUPG.

[John T. Farmer]

Hi, I'm testing the GNUPG 1.4.7 software downloaded from HP's freeware/opensource site. When encrypting a text file with a 3rd party company's public key, it says

"There is no assurance this key belongs to the named user"

It seems the answer has something to do with "Validating" this public key. Would appreciate any pointers on resolving this information message. Entering "Y" proceeds to encrypt the message.

Thanks,

John
john dot farmer at genworth dot com

[Hoff · Accepted solution]

Sign the public key with your private key.

eg:
"gpg --sign-key user-id"
or
"gpg --edit-key key-id"

Google has details. Toss out a few searches.

http://taosecurity.blogspot.com/2005/04/sending-encrypted-email-in-previous.html
http://www.nabble.com/Why-gpg-complains--td14971441.html
http://ask-leo.com/comments_009998.php?page=2

[Steven Schweda]

I recently had a private conversation with a
fellow who had the same complaint, and some
others ("gpg: WARNING: program may create a
core file!", and "gpg: Please note that you
don't have secure memory on this system",
even when it was installed with PSWAPM).

After some playing around, I found that
running my GPG seemed to repair the damaged
trust data base (or something) created by
HP's GPG, and that seemed to clear its "no
assurance" complaint.

Considering how briefly I looked at it, my
list of complaints about HP's kit is pretty
long, and, having concluded that it's
generally low-quality junk, I don't use the
thing, so I didn't look into it enough to
determine exactly what it does wrong in this
situation. (With my kit, I don't see this
problem, and that's good enough for me. I
assume that it's some file I/O problem, but
that's only speculation.)

My kit seems to work properly with a
keyserver, too. For a good time, try this
with the HP program:

alp $ gpg --search antinode schweda
gpg: searching for "antinode schweda" from hkp server subkeys.pgp.net
(1) Steven M. Schweda (Antinode)
1024 bit DSA key FA00E2F4, created: 2006-08-09
Keys 1-1 of 1 for "antinode schweda". Enter number(s), N)ext, or Q)uit > q

And the I/O should be faster, and it deals
better with an ODS2 file system, and you can
build it on a VAX, and the builder doesn't
disable optimization on an IA64 system to
cope with a problem in the VAX DEC C
compiler, and so on, and so on.

So, I suggest a visit to:

http://antinode.org/dec/sw/gnupg.html

Then wake me what _that_ one screws up.

[Steven Schweda]

> "gpg --sign-key user-id"

That would be with a _working_ gpg. With
HP's:

alp $ gpghp --sign-key sts@antinode.org
gpg: Please note that you don't have secure memory on this system
gpg: WARNING: program may create a core file!

pub 1024D/E6F4E9E8 created: 2008-04-23 expires: never usage: SC
trust: ultimate validity: unknown
sub 2048g/56F0AC1E created: 2008-04-23 expires: never usage: E
[ unknown] (1). Steven T. Schweda (Test keys)

"Steven T. Schweda (Test keys) " was already signed by key E6F4E9E8
Nothing to sign with key E6F4E9E8

Key not changed so no update needed.
alp $


I'm open to a good counter-example if it
works for you.

(Did I mention that my opinion of HP's GnuPG
is pretty low?)

[John T. Farmer]

Steven,

I'll have a look at your kit, and test this week. In the mean time, I have to implement the HP to get encryption working for a file transmission on Tuesday. I can limp by with it's quirks, I think.

On a different note, using the --homedir points you to a specific directory for the keyring. Can that be set somehow as a logical, so it doesn't have to be included on the command line? Each time I forget to use --homedir, the HP version, creates a new empty key ring under SYSLOGIN/GNUPG. I'm testing under one account, but will be running production jobs under another.

Thanks,

John F.

[Steven Schweda]

> Can that be set somehow as a logical, [...]

Yes and no. It looks as if default_homedir()
(in g10/misc.c) looks for GNUPGHOME, so you
might try setting that to a UNIX-like path
spec. However, if it thinks that it needs to
_make_ a directory (try_make_homedir() in
g10/openfile.c), it appears to go straight to
"~".

I believe that my only changes in this
neighborhood involved setting better
directory protections on [.gnupg] when
creating it, so whose edition you use
shouldn't matter on that front.

> [...] with it's quirks, [...]

That's "its", of course (as with "hi's" and
"her's").