encrypting to a user, "There is no assurance this key belongs to the named user"
Henry Hertz Hobbit
hhhobbit at securemecca.net
Fri Jun 21 16:06:55 CEST 2013
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 ]
rm -fr z00.gnupg
mv .gnupg z00.gnupg
# number others z01, z02, etcetera, if you want to keep a trail.
More information about the Gnupg-users