Re: [Evolution] Sometimes can't verify signature

On Sun, 2020-05-10 at 12:21 +0100, Pete Biggs wrote:
I created ~/bin/gpg2


echo $* > /home/lordbah/args.txt

What appears in args.txt is:

--verbose --no-secmem-warning --no-greeting --no-tty --batch --yes
status-fd=85 --verify-options show-photos --photo-viewer
/usr/libexec/camel-gpg-photo-saver --state "/tmp/camel-gpg-photo-
WDV3J0" --photo "%i" --keyid "%K" --type "%t" --verify
pgp.FCM3J0 -

I suspect that not all those are discrete arguments - try doing
something like this 

   for word in "$@"; do echo "$word"; done

this will put each argument on a different line.

/usr/libexec/camel-gpg-photo-saver --state "/tmp/camel-gpg-photo-state-
LFSCK0" --photo "%i" --keyid "%K" --type "%t"

That may wrap, but --state, --photo, --keyid, --type are all arguments
passed to the camel-gpg-photo-saver program. Everything else is a
separate argument to gpg2. Okay, today I DO find these options
documented in the gpg2 man page, don't know why I didn't find them
yesterday :-(  So just ignore this section. Sorry about that.

Hmm, the "bad" message has both a text/plain part and a text/html
wherease the "good" message has only a text/plain. I wonder if
an issue.

gpg version is 2.2.12.

In the structure of the message, does the GPG section cover the whole
of the message or just one section?

If you save the message and run it through GPG manually, does it

I've figured out how to do that for the message with the good signature
by removing everything above and below the first boundary (including
the boundaries). So the signature is in the separate file passed to the
--verify argument but it is not in the message passed on stdin. I
haven't figured out how to do that for this message with multiple parts
(or maybe I have and it's just not working for another reason).

gpg: CRC error; 04E96D - DC304E
gpg: no signature found
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.

But the signature file IS the first argument.

The numbers on the CRC error remain the same no matter what I do to the
message, so maybe it's telling me there is a problem with the signature
file rather than a problem with the message.

Is it possible that GPG is actually telling you the truth and that
something has modified the message in transit - it's not unknown that
ISPs modify HTML in messages to add web bugs, there were some free
providers in the past that added their own advertising banners into
HTML mail.

Thunderbird/Enigmail says the signature is good. I'll see if I can grab
the signature file it is extracting from the message to compare with
the one evolution is extracting.


evolution-list mailing list
evolution-list gnome org
To change your list options or unsubscribe, visit ...

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]