Debian Patches

Status for mutt/2.2.9-1+deb12u1

Patch Description Author Forwarded Bugs Origin Last update
debian-specific/Muttrc.patch Muttrc
* 2009-01-15 myon: refreshed for mutt-1.5.19; drop our list of ignored headers
in favor of upstream's new unignore list
Cristoph Berg <myon@debian.org> no 2014-02-27
debian-specific/882690-use_fqdn_from_etc_mailname.patch If /etc/mailname is present, the hostname inside the file will be
used, rather than calling gethostbyname() on the actual hostname.

This patch is based on Md.etc_mailname_gethostbyname.patch which did not apply
cleanly to mutt 1.9.1 so I decided to rewrite to use the mutt libraries.
no
debian-specific/use_usr_bin_editor.patch use_usr_bin_editor
Even if EDITOR is not set, mutt will always use /usr/bin/editor
(which is set by update-alternatives), rather than falling back
to vi.
Antonio Radici <antonio@debian.org> no 2014-02-27
debian-specific/correct_docdir_in_man_page.patch correct_docdir_in_man_page
Fix the link so it points to the correct docdir
and gzipped manual.
Antonio Radici <antonio@debian.org> no 2014-02-27
debian-specific/document_debian_defaults.patch document_debian_defaults
Some customization of the option which are straying
from the default only on Debian systems.
Antonio Radici <antonio@debian.org> no 2014-02-27
debian-specific/467432-write_bcc.patch 467432-write_bcc
The purpose of this patch is to alter the behavior of the write_bcc option
because exim4, the default SMTP in Debian, does not strip the Bcc headers; by
default write_bcc is set so this could cause a privacy leak.

The behavior that this patch introduces is: never write the Bcc header when the
message is sent, otherwise, if the message is sent to Fcc, then this optin
will be evaluated and the Bcc header will be written based on that.

Background discussion on this is in the following bugs:
http://bugs.debian.org/304718
http://bugs.debian.org/467432

This patch is a slightly modified version of the patch provided by
Stefan Vlkel <stefan@bc-bd.org> in the second bug.
Antonio Radici <antonio@debian.org> no 2014-02-27
debian-specific/566076-build_doc_adjustments.patch 566076-build_doc_adjustments
Use w3m to build the txt manual.
Antonio Radici <antonio@debian.org> no 2014-02-27
debian-specific/828751-pinentry-gpg2-support.patch This patch enables gpgme by default on the Debian version of mutt starting from
1.7.0-2. More explanations are in NEWS.Debian.
no
debian-specific/530584-default-tmpdir-to-var-tmp.patch [PATCH 1/2] Changed tmpdir default to /var/tmp
By default, mutt stores drafts in
/tmp/mutt-$HOSTNAME-$UID-$PID-$REV. /tmp is designed to hold data
that isn't guaranteed to be preserved between different invocations
of programmes. For practical purposes, and on Debian at least, this
translates to files being deleted on every boot, unless TMPTIME is
amended in /etc/default/rcS and /tmp is not a tmpfs.

This behaviour can cause loss of data, e.g. when the laptop dies or
turns itself off due to low power; the user might not have a chance
to commit the temporary mail draft s/he was working on to
non-volatile storage.

I suggest that mutt should use /var/tmp by default for its mail
drafts, as that directory is also temporary in nature, but cleaned
less frequently than /tmp. More specifically, the FHS dictates that
"files and directories located in /var/tmp must not be deleted when
the system is booted."

This patch modifies all occurrences of $tmpdir, $TMPDIR and Tempdir, but
not the documentation, which looks like it's generated from init.h.
martin f. krafft <madduck@madduck.net> no 2009-05-26
debian-specific/530584-default-tmpdir-to-var-tmp-docs.patch Adjust docs to reflect that the default TMPDIR is now /var/tmp, and not /tmp.
This is a follow up to 530584-default-tmpdir-to-var-tmp.patch
no
misc/gpg.rc-paths.patch gpg.rc-paths
Use the correct path of pgpewrap.
Antonio Radici <antonio@debian.org> no 2014-02-27
misc/smime.rc.patch smime.rc
Add CA's provided by ca-certificates to the ones
distributed by the default installation of Mutt.
Antonio Radici <antonio@debian.org> no 2015-09-15
upstream/528233-readonly-open.patch 528233-readonly-open
Open attachments as read-only so the editor won't be able to modify it;
otherwise the user can believe that he/she can edit it and risk to lose
his/her work (see upstream bug http://bugs.mutt.org/3261)

Debian bugs: #528233, updated in #572203
Antonio Radici <antonio@debian.org> no 2014-02-27
upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch Fix rfc2047 base64 decoding to abort on illegal characters.
For some reason, the rfc2047 base64 decoder ignored illegal
characters, instead of aborting. This seems innocuous, but in fact
leads to at least three crash-bugs elsewhere in Mutt.

These stem from Mutt, in some cases, passing an entire header
field (name, colon, and body) to the rfc2047 decoder. (It is
technically incorrect to do so, by the way, but is beyond scope for
these fixes in stable). Mutt then assumes the result can't be empty
because of a previous check that the header contains at least a colon.

This commit takes care of the source of the crashes, by aborting the
rfc2047 decode. The following two commits add protective fixes to the
specific crash points.

Thanks to Chenyuan Mi (@morningbread) for discovering the strchr
crashes, giving a working example draft message, and providing the
stack traces for the two NULL derefences.
Kevin McCarthy <kevin@8t8.us> no debian https://gitlab.com/muttmua/mutt/-/commit/452ee330e094bfc7c9a68555e5152b1826534555 2023-09-03
upstream/Check-for-NULL-userhdrs.patch Check for NULL userhdrs.
When composing an email, miscellaneous extra headers are stored in a
userhdrs list. Mutt first checks to ensure each header contains at
least a colon character, passes the entire userhdr field (name, colon,
and body) to the rfc2047 decoder, and safe_strdup()'s the result on
the userhdrs list. An empty result would from the decode would result
in a NULL headers being added to list.

The previous commit removed the possibility of the decoded header
field being empty, but it's prudent to add a check to the strchr
calls, in case there is another unexpected bug resulting in one.

Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
crashes, giving a working example draft message, and providing the
stack traces for the two NULL derefences.
Kevin McCarthy <kevin@8t8.us> no debian https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6 2023-09-04
upstream/Fix-write_one_header-illegal-header-check.patch Fix write_one_header() illegal header check.
This is another crash caused by the rfc2047 decoding bug fixed in the
second prior commit.

In this case, an empty header line followed by a header line starting
with ":", would result in t==end.

The mutt_substrdup() further below would go very badly at that point,
with t >= end+1. This could result in either a memcpy onto NULL or a
huge malloc call.

Thanks to Chenyuan Mi (@morningbread) for giving a working example
draft message of the rfc2047 decoding flaw. This allowed me, with
further testing, to discover this additional crash bug.
Kevin McCarthy <kevin@8t8.us> no debian https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0 2023-09-03

All known versions for source package 'mutt'

Links