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

[Henry Hertz Hobbit]

On 06/21/2013 10:22 AM, Peter Lebbing wrote:
> On 21/06/13 12:00, Henry Hertz Hobbit wrote:
>> Who or what is "gconf"? If that is what is actually used then
>> it is neither an email address or the keyid.
> 
> I don't think that's the problem, gpg is picking the key the OP wants, since it
> complains about key 468E35BC having insufficient validity.
> 
> Michael, what does --edit-key rconf tell you about key validity?
> 
> I don't know what's happening here, it looks to me like you're doing it
> correctly and it ought to just work. I tried to reproduce on my Wheezy system
> and couldn't reproduce it. But maybe I'm missing some detail.
> 
> Do you have any fancy stuff in your gpg.conf? Define "fancy stuff" broadly ;).
> Anything you feel comfortable sharing might be useful to mention.

Okay, try the following as a test since I had similar
problems with a version update and this got rid of my
problems (but their is no assurance it will help you
since my problems were slightly different but did not
manifest themselves until I had a GnuPG version jump
like what you just got):

1. Backup your key-folder in an xterm:
   $ cd ; rm -f gnupg.zip
   $ zip -r9 gnupg.zip ./.gnupg

2. Delete they key using gpg and make sure the trustdb entry
   for this key has also been removed.

3. Check to make sure you have an up-to-date version of the
   key and then --import it. lsign it again.

Now test it.  I am not saying it will work but it may.  There
may be a possibility your trustdb got fouled up somehow.  This
test is not catastrophic because you can always go back to
what you had:

$ if [ -s gnupg.zip ]
then
   rm -fr z00.gnupg
   mv .gnupg z00.gnupg
   unzip gnupg.zip
fi
# number others z01, z02, etcetera, if you want to keep a trail.