Help - Search - Members - Calendar
Full Version: Gpg There Is No Assurance This Key Belongs To The
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > Angstrom & OpenZaurus
grog
Hi all. When I try to encrypt a file, I get the following error:

CODE
$ gpg -e -r userid file.txt
gpg: #######: There is no assurance this key belongs to the named user

pub  #####/##### YYYY-MM-DD userid
Primary key fingerprint: ####
     Subkey fingerprint: ####

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

Now when doing this interactively I can answer 'y' & it works fine. But I need to do this in a script & it fails because of this. The same keys work fine on my bsd box & worked fine in all other Z installs so far (sharp based & previous OZ rom's). I also tried signing the key, which didn't make a difference. It's my own, so the private key is available as well, if that makes any difference.

This is the first time I've tried hentges, so there must be some difference in the install that causing this? Anybody have any ideas? thks
inode0
QUOTE(grog @ Sep 14 2005, 11:21 AM)
$ gpg -e -r userid file.txt
gpg: #######: There is no assurance this key belongs to the named user
...
This is the first time I've tried hentges, so there must be some difference in the install that causing this? Anybody have any ideas? thks

Have you set the trust level on your key?

gpg --edit-key name

and setting trust for your key to ultimate should take care of this.

John
inode0
QUOTE(inode0 @ Sep 14 2005, 12:28 PM)
Have you set the trust level on your key?

gpg --edit-key name

and setting trust for your key to ultimate should take care of this.

That wasn't very clear ... if you trust the key of the person you are encrypting this file for then you won't be asked about this stuff. Of course, you may want to encrypt files for folks with keys you don't ultimately trust, but do trust to some lesser degree.

You may be able to use the --encrypt-to option rather than the --recipients option to avoid the the trust checks in that case.

John
grog
QUOTE(inode0 @ Sep 14 2005, 06:28 AM)
QUOTE(grog @ Sep 14 2005, 11:21 AM)
$ gpg -e -r userid file.txt
gpg: #######: There is no assurance this key belongs to the named user
...
This is the first time I've tried hentges, so there must be some difference in the install that causing this? Anybody have any ideas? thks

Have you set the trust level on your key?

gpg --edit-key name

and setting trust for your key to ultimate should take care of this.
*

Worked like a charm. Since the key is my own (i'm encrypting files for storage, not to be sent), trust isn't an issue (I do trust myself most of the time smile.gif).

I wonder why I haven't needed to do this before (on other systems)? Maybe the openssh package has different compile-time options now? I certainly couldn't find any command-line options to affect this.

Thanks very much, John.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.