| Commit message (Collapse) | Author | Age | Lines |
|---|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
It's very old behavior, but doesn't seem to be documented anywhere.
Thanks to Charles for pointing that out.
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 012981e8 (in release 2.2.9) updated the GPGME autoconf files,
to fix a build issue with newer GPGME releases.
Unfortunatley that caused a build issue for hosts where the gpg-error
header files aren't in the include path. The newer autoconf file
expect GPG_ERROR_CFLAGS to be added to the list of flags for the
compiler.
Thanks to Will Yardley for reporting the issue and quickly testing the
proposed fix.
|
| | |
| |
| | |
accepting old/insecure smime certificates
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When uncollapsing, _mutt_traverse_thread() returns the virtual number
of the root message in the thread. <collapse-thread> directly sets
menu->current to this value to cause the cursor to be on the *first*
message of the thread (which isn't the same as the root message when
sort=reverse-threads). <collapse-all> finds the corresponding message
by searching for it after re-indexing.
However, when collapsing, _mutt_traverse_thread() had code to try and
find the *first* message in the thread and return that virtual number.
<collapse-thread> then did the same trick, because the old first
message is now the new root message for sort=reverse-threads.
However, that cleverness caused a bug for <collapse-all> - it can't
use that virtual number directly, and it can't "find" the message at
the index after reindexing.
To fix this, remove the cleverness from _mutt_traverse_thread() when
collapsing. Return the virtual number of the root. Add searching
behavior for <collapse-thread> to fix its behavior.
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| | |
This is generated from the copyright-updater script, with manual
updates for the main.c and documentation, and po files.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't want to copy the deleted flag over to the trash folder too.
I looked into various ways to keep the UID COPY, but they lead to
niggling issues with error handling along with handling if the server
sends flag updates back to the client.
So for that (hopefully rare) case, abort the fast trash and just use a
regular copy.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Split XOAUTH2 to use two steps.
This follows the microsoft.com documentation example for smtp. Since
office365 is the main site using XOAUTH2 now, it's better to match
their documentation.
It also matches msmtp's behavior, which probably means somewhere or
another needs it that way.
At the same time, improve response code checking. Mutt was using
smtp_get_resp() before, which returns 0 for both a ready and success
response code. Make sure it's a success response code when done
authenticating.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The character '/' from base64 alphabet breaks web redirectors if the
message-id from an email is used as part of the URL for redirectors and/
or automatic pointers to an email.
Use the URL safe alphabet from RFC4648 section 5 for message id
generation.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
In the base64 safe URL dictionary the characters '+' and '/' are
replaced by '-' and '_'.
Add the characters to Index_64 to allow decoding if needed.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are cases when using the 'authcode' grant where the authorization
request will succeed but the access token request will fail (for
example: if the user's web browser and terminal use different proxy
settings). The current implementation of the script does not inform
the user that the authorization token is being exchanged for an access
code, with the result that it can appear that a request has both
succeeded (according to the browser) and failed (according to the
terminal output) simultaneously. Add a message to inform the user that
a second request is being made so there is less potential for confusion.
|
| |\| |
|
| | |
| |
| |
| |
| | |
I think it probably makes more sense to be inside the (if) function
documentation than (equal).
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The maildir_check_mailbox() code was not updating the context deleted
and trashed counts in those cases. This could lead to messages marked
as deleted, but no action being taken on a mailbox sync/close.
wip: fix ctx counts for maildir 'T' flags updates.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
There doesn't appear to be any relationship between $mark_old and "new
mail" status any more.
Commit c26c2531 (from 2002) is the most recent commit that talked
about reducing the meaning of $mark_old, and may have been the commit
to make that separation.
|
| | |
| |
| |
| |
| | |
They evaluate to "yes" and "no", and so need an explicit comparison to
those values when using the equal function.
|
| | |
| |
| |
| | |
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
|
| | |
| |
| |
| |
| | |
If the working_dir was empty, it would be set to $folder, which isn't
helpful if it's a IMAP directory. Instead set it to cwd.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously there was only one "last" location stored, shared between
file and mailbox operations when the MUTT_SEL_FOLDER flags was passed.
This meant adding attachments to a composed message would start in the
"mailbox" place (which could be an IMAP folder). Then, a subsequent
change-folder would start in the attachment directory browsed to.
Create two different flags, MUTT_SEL_MAILBOX and MUTT_SEL_FILE and use
those to use the corresponding "last" variable.
Change the browser function to use a temporary buffer, working_dir,
instead of directly manipulating LastDir.
Change callers to use the appropriate flag based on their usage.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On an unreliable connection (e.g., laptop put to sleep and changing wifi
networks) I've had mutt fairly regularly become stuck in SSL_read and
have to be killed.
Per some of the comments on
https://stackoverflow.com/questions/46517875/ssl-read-blocks-indefinitely
adding a timeout to the socket should carry over to the SSL_read call.
Using this socket_receive_timeout option appears to resolve the issue
for me.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I partially changed this to lazily update after a thread update in
commit c9fa0414, but unfortunately didn't investigate the reason for
the color update while setting a flag. Since it was that way, I
assumed it was for a purpose.
However, it turns out there is no need to actively set the header
color in that function. Many places in Mutt already simply reset the
color values to 0 to invalidate and cause a recheck later.
Setting the color there so can even be detrimental, if the user has
slow 'color index' lines. For example doing a <tag-pattern>~A will
cause the color to be computed for the *entire* mailbox. Now, the
user ought to not have a slow color index line, but if they do, this
causes unnecessary pain.
Note that the header->color doesn't have an actual "unset" value,
which could also help performance. Maybe in the future in master
branch.
|
| |\| |
|
| | |
| |
| |
| | |
"U+200C ZERO WIDTH NON-JOINER" is generating '?' on some systems.
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This is useful for octal values of greater (or less) than three
digits.
|
