Dear Maintainer, with your last update you set „crypt_use_gpgme=yes” in „/etc/Muttrc.d/gpg.rc”. While this setting works with PGP signed mails, trying to open SMIME mails leads to a hanging mutt (more than one minute). Looking at the process list I see gpgsm is started. After several minutes the mail is opened but the signature could not be verified. When I set crypt_use_gpgme to no then mutt opens the mail at once. Openssl is used to check the signature and the signature can be verified. I don’t see anything in the documentation what I have to change to get gpgsm working. The changes only speak about the new gpg handling. Many greetings, Stephan
Control: severity -1 important This is not good, let me investigate it and I'll get back to you.
- Josh Triplett
Apparently the problem can be reproduced on Debian Sid with Mutt 1.10.0-1. Opening S/MIME emails results in Mutt hanging for a long time - in my case approximately 20 seconds. In my case, a pop up opens that says "Do you ultimately trust [a certain CA] to correctly certify user certificates?" - which I think comes from https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/trustlist.c;h=af177b2e26a3647370a0420e2b531ed47d79adcb;hb=HEAD#l664 I can either confirm you "ultimately trust" the CA or reject it - but if I reject it the delay will not go away. Confirming ultimate trust, conversely, will "fix" (so to speak) the delay. It is not clear to me whether it is more of a Mutt problem or rather with GnuPG / gpgme. Thanks for your help. Kind regards,
FWIW, I was having this problem today with mutt 1.7.2-1 from stretch,
and I was not able to get around the delay. Sometimes I see some
full-screen dialog, possibly made with ncurses, asking about if I should
accept a (self-signed?) certificate, but I was not able to interact with
it. I didn't wait for the delay, but killed the gpgsm process from a
different terminal to get back to mutt. Mutt then says "S/MIME signature
could NOT be verified", and shows "Error: verification failed: End of
file" in the mail body:
[-- Attachment #1 --]
[-- Type: multipart/signed, Encoding: 7bit, Size: 45K --]
[-- Begin signature information --]
Error: verification failed: End of file
[-- End signature information --]
[-- The following data is signed --]
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: quoted-printable, Size: 2.6K --]
Given that the mutt package in stretch is really a mutt with neomutt
patches, I tried the neomutt 20180512+dfsg.1-1 from unstable, which
works better. There is no delay, but it also says "S/MIME signature
could NOT be verified". However, it shows openssl output in the mail
body instead:
[-- Attachment #1 --]
[-- Type: multipart/signed, Encoding: 7bit, Size: 45K --]
[-- OpenSSL output follows (current time: Mo 11 Jun 2018 12:56:04 CEST) --]
Verification failure
139830712489216:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:../crypto/pkcs7/pk7_smime.c:285:Verify error:self signed certificate in
certificate chain
[-- End of OpenSSL output --]
[-- The following data is signed --]
[-- Attachment #1 --]
[-- Type: text/plain; charset=utf-8, Encoding: quoted-printable, Size: 2.6K --]
I also tried setting "pinentry-program /usr/bin/pinentry-tty" in my
~/.gnupg/gpg-agent.conf, but that didn't change the behaviour in
strech-mutt. Neither did setting "set smime_ask_cert_label = no" in my
muttrc.
- Roland
Hello, Hope you are doing well. We are Yiwu Derui Arts & Crafts Co., Ltd., a factory with main products: canvas, framed art, art mirrors. If you are interested in these products, please feel free to ask us for presentation copy. Hope there is a chance to be your supplier. Waiting for our kindly reply. Regards Ari
Hi, this bug still exists with mutt 1.10.1-2.1, and I'm unable to work around the issue. Could you provide any solution or workaround? Antonio, how are your investigations going? Thanks, Carsten
fixed 838361 1.14.4-1 thanks This bug does not happen in the most recent version of mutt in sid. I believe this was a regression from neomutt.
retitle 988127 neomutt hangs for minutes while checking S/MIME signed mails found 988127 20201127+dfsg.1-1.1 thanks Heya, I've cloned/reassigned this issue from mutt to neomutt, because it does happen to me with neomutt right now (version 20201127+dfsg.1-1.1 ), exactly as described in the original mutt bug report. Cheers
Control: found -1 20220429+dfsg1-4.1 It happens for me also with latest version of neomutt. @Antonio, could you please consider to investigate this?
Hi all,
I've done some code review to figure out what we can do to
workaround/fix this issue since it has annoyed me in the past and I
just don't even want to use S/MIME ever really.
Some things I found: since I set crypt_use_gpgme=yes gpgme apparently
handles S/MIME directly (didn't know gpg supported it) and the
"backend" is /usr/bin/gpgsm.
So a very nasty hack is to get rid of this issue is to just symlink
gpgsm to /usr/bin/false somewhere on your $PATH:
# ln -s /usr/bin/false gpgsm
Looking at the code I found the original sin to be at
ncrypt/cryptglue.c:crypt_init:
#ifdef CRYPT_BACKEND_GPGME
if (c_crypt_use_gpgme)
{
crypto_module_register(&CryptModPgpGpgme);
crypto_module_register(&CryptModSmimeGpgme);
}
#endif
this makes it so crypt_use_gpgme=yes enables both gpg and smime
support with no way to disable smime at init or message verification
time. Not even hooks will help since the crypt module registration
runs only once.
IMO this is unacceptable as I have no interest in being exposed to the
vulnerability surface area of smime despite not having any use for it,
so I'm planning to propose a patch to neomutt to move the smime
registration to a seperate rc variable.
Does anybody think the ability to toggle this per-message would be
useful? I can't think of a compelling reason to want that.
Hi Daniel, Thanks for investigating this one, really! I really think this should be handled upstream, so I've forwarded your findings to them [1]. I can't either, but who knows :-) Cheers, Charles [1] https://github.com/neomutt/neomutt/issues/3068#issuecomment-2132481854