On Mon, 2016-05-23 at 11:13 +0200, Milan Crha wrote: > On Sun, 2016-05-22 at 20:01 +0100, Patrick O'Callaghan wrote: > > > > I attempted to send an encrypted and signed email to two > > recipients. > > Every time I would get the following error message: > > > > Could not create message. > > > > Because "gpg: skipped "XXXXXXXX": No secret key > > gpg: signing failed: No secret key > > ", you may need to select different mail options. > > > > Naturally my focus was on trying to figure out what was wrong with > > my > > secret key (which I had successfully used before, and from Evo). > Hi, > the two lines with "gpg:" prefix are raw output from the gpg itself. > The evolution(-data-server code) interprets some of the output, but > not > all of it. > > Was the "XXXXXXXX" an email address or a key ID?
I tried both. They gave exactly the same error. > I agree with you that the gpg's "signing failed" is misleading, > because what failed was the "encrypting", not "signing". The main problem for me was that reason given for the failure was completely wrong. It had absolutely nothing to do with my secret key, causing me to waste several days (not full-time of course) trying to diagnose a non-existent issue with my GPG installation. > When I tried the same, send a signed and encrypted message using GPG > from the evolution, then I was asked for my own key password first, In the case when I got the error message, Evolution never asked for my passphrase. It only did so when I removed the offending destination. That reinforced the idea that there was a problem with my secret key. > then I received the same error, with a more extensive text: > gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX > gpg: using PGP trust model > gpg: This key belongs to us > gpg: <a@b.c>: skipped: No public key > gpg: [stdin]: encryption failed: No public key > Thus my gpg version claims a better error (I used the "a@b.c" as the > recipient). This is with the development version of the evolution (- > data-server), 3.21.2, which calls /usr/bin/gpg2. I tried also with > the > /usr/bin/gpg, but it provides the same error message here. > I'm using gnupg2-2.1.11-3.fc24.x86_64, gnupg-1.4.20-2.fc24.x86_64. I agree that is better, in that is does give the real reason for the failure. However the error message itself is far too obscure for the average user to be able to parse it, and comes at the end of a series of diagnostic messages which aren't relevant unless you're trying to debug it. I note from the gpg manpage that the option --status-fd can be used to get encoded status information, including whether signatures are good and encryption has been successful. This might be a better way to generate more user-friendly error messages. poc _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
