| 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/980924-updated-german-translation.patch | no | |||||
| upstream/985152-body-color-slowness.patch | [PATCH] Improve body color matching speed by caching future matches. On a *very* long body (or header_partial) lines with multiple color lines that match, performance can be degraded. For instance if there were moderately expensive regexp matches against "A" "B" and "C". A line with: A A A A A B A A C A A A B A A A C The B and C regexps were scanned again after every "A" match, despite that the result would be discarded again for the next A match. Change the color matching to cache the location of each color line match. Discard the cache once the match offset passes that point. |
Kevin McCarthy <kevin@8t8.us> | no | 2021-03-10 | ||
| upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch | Fix seqset iterator when it ends in a comma. If the seqset ended with a comma, the substr_end marker would be just before the trailing nul. In the next call, the loop to skip the marker would iterate right past the end of string too. The fix is simple: place the substr_end marker and skip past it immediately. |
Kevin McCarthy <kevin@8t8.us> | no | debian | https://gitlab.com/muttmua/mutt/-/commit/7c4779ac24d2fb68a2a47b58c7904118f40965d5 | 2021-05-03 |
| upstream/Fix-uudecode-buffer-overflow.patch | Fix uudecode buffer overflow. mutt_decode_uuencoded() used each line's initial "length character" without any validation. It would happily read past the end of the input line, and with a suitable value even past the length of the input buffer. As I noted in ticket 404, there are several other changes that could be added to make the parser more robust. However, to avoid accidentally introducing another bug or regression, I'm restricting this patch to simply addressing the overflow. Thanks to Tavis Ormandy for reporting the issue, along with a sample message demonstrating the problem. |
Kevin McCarthy <kevin@8t8.us> | yes | debian upstream | https://gitlab.com/muttmua/mutt/-/commit/e5ed080c00e59701ca62ef9b2a6d2612ebf765a5 | 2022-04-05 |
| upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch | [PATCH] Fix gpgme crash when listing keys in a public key block. The gpgme code handling classic application/pgp assumed each key would have a uid. Change it to check for a missing uid list. Also change it to list every uid (instead of only the first), and to put each one on a "uid" line in the output. The output is only for display, so the format change won't affect other parts of the code. Thanks to Mikko Lehto for the high quality bug report, detailing the exact place of the crash with a reproducing example and a workaround patch. |
Kevin McCarthy <kevin@8t8.us> | no | 2022-10-31 | ||
| upstream/Fix-public-key-block-listing-for-old-versions-of-gpg.patch | [PATCH] Fix public key block listing for old versions of gpgme. Commit 382355a5 accidentally removed the data import for legacy mode, which would cause it to produce empty output. |
Kevin McCarthy <kevin@8t8.us> | no | 2022-10-31 | ||
| upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch | [PATCH] Add a check for key->uids in create_recipient_set. For gpgme < 1.11.0, it used this function to create the encryption key list. The '!' was interpreted differently back then, and it apparently didn't check if the returned key had any uids before referencing it. Add a check to prevent a segv as in the public key block fix. |
Kevin McCarthy <kevin@8t8.us> | no | 2022-11-01 | ||
| 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 |