Connecting to IMAP with mutt built against openssl always asks to accept the certificate on restarting mutt, though "always accept" has been selected. The same procedure works without problems when built against gnutls. Installing the ca_cert doesn't solve the problem in mutt, but connecting directly via "openssl s_client ..." works. Reproducible: Always Steps to Reproduce: 1. USE="-gnutls ssl" emerge mutt 2. try connection to an IMAPs 3. accept the cert 4. restart mutt 5. accept it again 6. *loop* Actual Results: asks every time for cert-acceptance Expected Results: only ask once Upstream is informed - http://dev.mutt.org/trac/ticket/3426 A patch has been submitted, but it's against the current HEAD and I'm not able to backport it.
Why can't you apply juml's patch? Does it perhaps rely on changeset 6016:dc09812e63a3 which might not be in -r15?
(In reply to comment #1) > Why can't you apply juml's patch? Does it perhaps rely on changeset > 6016:dc09812e63a3 which might not be in -r15? > Yes, the relevant code-structure in our -r15 and upstreams current version has changed, so the line-offset and the patch itself needs to be different. Since C isn't my "native language"^^ and this is a security-related part, I don't want to "debianize" it and rather leave it to someone with the proper knowledge. The patch itself seems to work, at least I pulled and built the latest version from there hg and I don't see the problem there.
ok, thanks, I'll look into it tonight.
I don't really get it, since the patch as provided by julm is already in the sources, unless he meant the reverse of it. -r15 contains dc09812e63a3, as does "the latest version from hg" (HEAD branch that is).
PS. I use imaps from mutt all day, and I cannot reproduce this. What are your USE-flags? vanilla or sidebar by chance?
(In reply to comment #5) > PS. I use imaps from mutt all day, and I cannot reproduce this. What are your > USE-flags? vanilla or sidebar by chance? > Yes, I had USE="sidebar" in my flags, but recompiled with: > USE="crypt gdbm gpg idn imap nls nntp smtp ssl" emerge mutt deleted my ~/.mutt/certs, started mutt, accepted, closed and restarted mutt and the same behaviour as noted above happens again. Maybe you got BOTH USE="gnutls ssl" in your flags and gnutls gets prefered?
Erm, ok, concerning HEAD you're right, wonder what I compiled there, but as a matter of fact, whatever it is I compile, as long as I don't have USE="gnutls" it fails.
USE=sidebar implies USE=vanilla. USE=vanilla excludes most patches and gets you to use a pristine mutt tarball (as released ages ago, lacking all the useful fixes) If you compile using USE="-sidebar -vanilla ssl" you should see it working, simply because you get the proper fixes applied (the jumbo patches that make all the Gentoo revisions).
(In reply to comment #8) > If you compile using USE="-sidebar -vanilla ssl" you should see it working, > simply because you get the proper fixes applied (the jumbo patches that make > all the Gentoo revisions). Maybe I should see it working that way, but I don't. Recompiled with USE="crypt gdbm gpg idn imap nls nntp smtp -gnutls -sidebar -vanilla", same faulty behaviour occures.
Erm, damnit, forgot the "ssl" above, still it's compiled with that and doesn't work. Maybe it's a special problem with my hosting?
please post the output of mutt -v
(In reply to comment #11) > please post the output of mutt -v > [~] mutt -v Mutt 1.5.20 (2009-06-14, Gentoo 1.5.20-r15) 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: Linux 2.6.34-gentoo-r1 (x86_64) ncurses: ncurses 5.7.20081102 (compiled with 5.7) libidn: 1.19 (compiled with 1.19) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Mar 30 2010 18:15:38) Compile options: -DOMAIN -DEBUG +HOMESPOOL -USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL +USE_FLOCK -USE_POP +USE_NNTP +USE_IMAP +USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +COMPRESSED +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="Maildir" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc/mutt" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to <mutt-dev@mutt.org>. To report a bug, please visit http://bugs.mutt.org/. dgc.subjrx fg.smarttime vvv.initials vvv.quote vvv.nntp patch-1.5.6.dw.mbox-hook.1 rr.compressed patch-1.5.4.lpr.collapse_flagged Lukas P. Ruf <lukas.ruf@lpr.ch>
Any new input on this? At least neither the new mutt-...-r16 nor the openssl-1.0x update fixed it.
Upstream ignores, there's not much more I can do about it then. I have no clue how it works.
I've played a little more with mutt/openssl today and now - finally - I know what the problem is. So, I've got my mails on my own domain, which in turn lies on a shared webspace server. Thus my 'mail.mydomain.tld' redirects to 'foo.bar.tld', where the latter is also the host named in the certificate. Now, for some reason, something in the chain of mutt/openssl is extremly strict and doesn't correctly accept the cert if I use > set spoolfile = imaps://mail.mydomain.tld but if I use > set spoolfile = imaps://foo.bar.tld it works and of course doesn't even ask me to accept the cert, since the hostname now matches it. I'd like to use mail.mydomain.tld though, so I don't have to wonder why things break, if I come to change my provider one day. While this is an acceptable workaround, the question remains, if this is intended behaviour and if it is, why is it different between mutt using gnutls or openssl?
