Re: Security findings

Alejandro Colomar via Mutt-dev <[email protected]> Sun, 19 Apr 2026 19:48:42 +0200
Newsgroups	gmane.mail.mutt.devel
Message-ID	<aeUVQL56_1COSFCO@devuan>
Hi Matthias,

On 2026-04-19T15:36:05+0200, Matthias Andree via Mutt-dev wrote:
> Am 18.04.26 um 17:42 schrieb Kevin J. McCarthy:
> > On Sat, Apr 18, 2026 at 09:27:59PM +0800, Kevin J. McCarthy wrote:
> > > On Sat, Apr 18, 2026 at 02:14:53PM +0200, evilrabbit via Mutt-dev wrote:
> > > > Please find below a number of confirmed security findings in the
> > > > mutt client.
> > > > None of these are significant but should probably be addressed.
> > > 
> > > Thanks, I will start taking a look at these tomorrow.
> > 
> > Just as a note to the other devs.  I started looking at some of these
> > tonight.
> > 
> > I've pushed up to gitlab some (very quickly made) branches:
> >   kevin/stable-security-01        Fix NULL dereference in
> > show_sig_summary().
> >   kevin/stable-security-02        Fix infinite loop in gpgme
> > data_object_to_stream().
> >   kevin/stable-security-05        Fix IMAP auth_crm MD5 digest of secret
> > to use memcpy().
> >   kevin/stable-security-06        Fix imap_auth_gss() security_level
> > size.
> >   kevin/stable-security-07        Check for embedded nul in
> > url_pct_decode().
> >   kevin/stable-security-08        Abort if there are DNS entries but
> > don't match.
> > 
> > These still need to be cleaned up, verified, and tested.
> > 
> > For #8 I need to check the RFC myself, so if anyone with OpenSSL code
> > experience wants to confirm that would be welcome.
> > 
> > For #3, I'm not sure if we really need to fix this.
> > 
> > For #4, I welcome input from others about this.  Randomizers are not my
> > thing.  If the algorithm is insufficient for what we are using it for,
> > then I welcome help in implementing something better.
> > 
> Re #8, it's been a while since I'd read the standards (RFC 5280 and 6125),
> but what's in the OP matches my recollection. I find the check plausible and
> correct. There might be improperly issued certificates afoot (I've also seen
> even some CA issue certificates with serial number 0, which wolfSSL would
> reject) so with that change merged, mutt starts rejecting certificates -
> that don't repeat or pattern match the CN in the SAN - that it used to
> accept, so this should be announced as a "breaking change" in the NEWS.
> 
> Also, I wonder if I'd personally want to repeat the match_found=0
> initialization redundantly so I have a safety net if I were to edit the code
> later. Might trigger compiler warnings though because the compiler can prove
> it's redundant.

I'd prefer not adding dead code.  It helps in the short term, preventing
dumb mistakes, but complicates the logic of the code, which in the long
term can lead to confusion and more subtle bugs.


Have a lovely day!
Alex

> 
> -- 
> 
> Matthias Andree
> 

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)