Re: GPGME backend fails to select PGP key ID for encryption
On Fri, Mar 02, 2012 at 09:17:59PM +0100, Nikola Pavlović wrote: Hi all, Recently I switched to Mutt 1.5.21 from latest 1.4, mostly so I could use gpgme backend for GnuPG instead of the old command based one. Everything works fine except for the weird behaviour when I try to encrypt email: Mutt keeps asking me to manually select the recipient key ID via 'Enter keyID for em...@example.com' prompt. I tried entering the key ID in all possible formats but apparently it just ignores the input and keeps asking. After I break from it with Ctrl-g, I get the following error: 'gpgme_new failed: Not operational'. Of course, the recipient key is present on the keyring, the email in 'To' field matches the one in the UID field of the key etc. None of this ever happened in 1.4.x. The key in question wasn't signed yet (I haven't validated it), so I tried signing it with level 1 (i.e. 'I haven't verified the key at all' level) just to see if the signature makes any difference and it didn't work. Likewise, when I tried with a level 0 or 2 signature (which are accepted by GnuPG as valid in my and the default configuration). I tried the same thing with other recipients--same story. Basically, I cannot encrypt any email. Note that verifying signatures made by these, or any other keys works (so GnuPG is definitely aware of them and Mutt can, in principle, select them). Just to give some more info now that I had more time to fiddle with this today. What led me to believe this has something to do with certification and trust was the fact that all examples of pgp_encrypt_only_command and pgp_encrypt_sign_command have --always-trust gpg flag in them. I never paid much attention to it, but now that I have it seemed odd to me, so I thought there might be some strange reason to require this and it's not 'activated' when using GPGME backend. So today I tried every possible combination of cert and trust levels on a key (including trust signatures) with no results. I also tried adding trust-model always to gpg.conf, again with no luck. In the end, I just switched to classic backend and, as I expected, things are working again--Mutt is able to select the correct key. Oh well, good enough I guess, the really important thing for me is the ability to use gpg-agent from within Mutt. GPGME just seemed like a more correct way to do things. I would still like to solve the problem though. If I catch some more time I'll try to build Mutt with --enable-debug and/or dig through the source, but in the meantime if anyone has any ideas let me know please. P.S. I stumbled upon http://dev.mutt.org/trac/ticket/3564, and vague and non-actionable as it is, it gives me some hope that the problem is not local to my machine. :) -- Ah say, son, you're about as sharp as a bowlin' ball.
Why the --always-trust flag in encryption commands?
As I said in my previous thread, I never paid much attention to PGP commands in muttrc (mostly because the given sample always worked), so now that I have, I'm curious about the purpose of --always-trust flag to GnuPG in pgp_encrypt_only_command and pgp_encrypt_sign_command options. It's there in every single example of these options on the Internet, but I just don't see what does a particular trust model have to do with encrypting a message (not to mention forcing one). GPG itself lets me encrypt a file to a recipient whom I marked as untrusted (and whose key I haven't certified) without problems. Just for fun I left out the flag from my muttrc, and it doesn't seem to have any effect, the key is selected properly and so on, just like when the flag was there. So my question is: What am I missing and how am I shooting myself in the foot by leaving it out? :) -- Cinemuck, n.: The combination of popcorn, soda, and melted chocolate which covers the floors of movie theaters. -- Rich Hall, Sniglets
GPGME backend fails to select PGP key ID for encryption
Hi all, Recently I switched to Mutt 1.5.21 from latest 1.4, mostly so I could use gpgme backend for GnuPG instead of the old command based one. Everything works fine except for the weird behaviour when I try to encrypt email: Mutt keeps asking me to manually select the recipient key ID via 'Enter keyID for em...@example.com' prompt. I tried entering the key ID in all possible formats but apparently it just ignores the input and keeps asking. After I break from it with Ctrl-g, I get the following error: 'gpgme_new failed: Not operational'. Of course, the recipient key is present on the keyring, the email in 'To' field matches the one in the UID field of the key etc. None of this ever happened in 1.4.x. The key in question wasn't signed yet (I haven't validated it), so I tried signing it with level 1 (i.e. 'I haven't verified the key at all' level) just to see if the signature makes any difference and it didn't work. Likewise, when I tried with a level 0 or 2 signature (which are accepted by GnuPG as valid in my and the default configuration). I tried the same thing with other recipients--same story. Basically, I cannot encrypt any email. Note that verifying signatures made by these, or any other keys works (so GnuPG is definitely aware of them and Mutt can, in principle, select them). Does anyone have any idea what could be the problem? I tried searching, but haven't found anything other than people having similar problems with 'Enter keyID' prompt not accepting manually entered key IDs but nothing specific to my problem. I'm running Mutt with GnuPG 2.0.18 on FreeBSD 8.2 (now actually on 8.3-BETA1, but it doesn't make a difference) with the following Crypto and PGP options in muttrc: set crypt_autosign=yes set crypt_autosmime=no set crypt_replysignencrypted=yes set crypt_use_gpgme=yes set pgp_auto_decode=yes set pgp_show_unusable=no mutt -v output: Mutt 1.5.21 (2010-09-15) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: FreeBSD 8.3-BETA1 (i386) ncurses: ncurses 5.7.20081102 (compiled with 5.7) libiconv: 1.13 libidn: 1.22 (compiled with 1.22) Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP -USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/local/share/mutt SYSCONFDIR=/usr/local/etc EXECSHELL=/bin/sh -MIXMASTER To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. patch-1.5.0.ats.date_conditional.1 dgc.deepif.1 -- If at first you don't succeed, quit; don't be a nut about success.
