SeidlS at schneider.com
SeidlS at schneider.com
Tue Jun 27 18:12:16 CEST 2006
One of the options we tried to resolve this was to remove the key from the
key ring (--delete-key), re-import it, and then re-sign it. We continued
to get the same error after completing those steps. Shouldn't this have
removed any expired signatures? Also, another user ID has the same key in
the keyring, and isn't having any issues.
Our key is setup to expire every year, and last year we added a new subkey
with a new expiration date. So the key we use for signing does have one
subkey that is expired, and one that will expire in September. Is this
contributing to the problem we are currently having?
Electronic Communication Services
seidls at schneider.com
This document, and any attachments therein, contains proprietary and
confidential information that may not be disclosed without the prior
written permission of Schneider National, Inc. and its subsidiaries.
Unauthorized use or misuse of this information and its contents is strictly
prohibited. Schneider National, Inc. vigorously protects its rights.
<dshaw at jabberwock
Sent by: gnupg-users at gnupg.org
es at gnupg.org
Re: Trust Issue
On Mon, Jun 26, 2006 at 04:18:34PM -0500, SeidlS at schneider.com wrote:
> Can someone explain to me what would have occurred within gpg to cause
> following error:
> gpg: Warning: using insecure memory!
> gpg: using secondary key 11111111 instead of primary key 11111111
> Could not find a valid trust path to the key. Let's see whether we
> can assign some missing owner trust values.
> No path leading to one of our keys found.
> 1024g/11111111 2001-06-11 "XXXXXXXXXXXXXX"
> Fingerprint: aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
> It is NOT certain that the key belongs to its owner.
> If you *really* know what you are doing, you may answer
> the next question with yes
> Use this key anyway?
> The process using this key was working fine last Wednesday, but quit
> working last Thursday. There were no changes (imports, edits, or
> to the key ring or the trustDB during that time.
> I have googled for the errors and have a work around in place (added
> --always-trust to the options file), but am curious what would have
> this issue, and what needs to be done to resolve?
Most likely, a signature somewhere in the trust chain expired.
Expired signatures do not carry trust.
Gnupg-users mailing list
Gnupg-users at gnupg.org
More information about the Gnupg-users