Re: GPG and good signature (mis?)behaviour
Hi Todd, and thanks for your reply.
On date Tuesday 2007-05-01 10:37:13 -0400, Todd Zullinger muttered:
> Stefano Sabatini wrote:
> > Hi mutters,
> >
> > I'm getting this strange behaviour when I try to verify the integrity
> > of a message with mime type multipart/signed and signed with PGP.
> >
> > In most cases it works just fine, but in some cases I get something
> > as:
> >
> > [-- PGP output follows (current time: Tue 01 May 2007 03:50:24 PM CEST) --]
> > gpg: Signature made Tue 01 May 2007 03:34:27 PM CEST using DSA key ID
> > XXXXXXXX
> > gpg: Good signature from "xxxxxx xxxxxxx <xxxxxxxxxxxxxxxxxxxx>"
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg: There is no indication that the signature belongs to the
> > owner.
> > Primary key fingerprint: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
> > [-- End of PGP output --]
>
> The important part is the gpg warning. It means that the key used to
> sign the message isn't signed (certified) by your key (or the key of
> someone else that you've marked as trusted).
>
> You can test this by adding a local signature to a key for which this
> happens (gpg --lsign-key <keyid>).
I discovered this behaviour is dependant on the folder I'm exploring.
There happens to be "good" folders and "bad" folders, in the good ones
I can see the "s" flag right just when I open them in the index and
the verify mechanism works as expected (that is good signatures
results in a "S" flag), in the bad ones I can't see the "s" when
opening them in the index, but it appears when I display the
corresponding mail in the pager, and the "s" doesn't become "S" after
I verify them even if they are good (according to the gpg output).
I tried to figure out some relevant difference between the good and
bad folders (I'm using maildir formats), but without success... very
puzzling, so I have to conclude this is a rather strange bug.
Anyway, apart from the strange "s"/"S" inconsistency, the gnupg output
seems correct (I verified ti with corrupt signatures), so it means I
don't have to blindly trust stupid flags ;-).
Kind regards
--
mutt tip #4
You can improve the modularity of your mutt configuration using the source
command.
Usage:
source <filename>