Kevin McCarthy [Wed, 17 Apr 2019 01:11:35 +0000 (18:11 -0700)]
Convert other users of BUFFY->pathbuf to use BUFFERS.
A few functions in browser.c, buffy.c, and monitor.c were using
BUFFY->pathbuf but were potentially truncating via fixed size buffers.
Convert those to use BUFFERS too.
buffy_get() was creating epath and expanding it, apparently to match
against expanded BUFFY list entries, was wasn't using the epath. I
believe this is a bug, and have switched the comparison to epath.
Kevin McCarthy [Tue, 16 Apr 2019 20:41:10 +0000 (13:41 -0700)]
Convert BUFFER->path to a BUFFER.
Rename to BUFFER->pathbuf to make it clear the field is a BUFFER, and
to make sure to catch and review all usages.
There are still uses of pathbuf that are truncating and need to be
fixed, for example in browser.c and buffy.c.
Fix up sidebar usage in one place, that was pointing inside the
BUFFY->path with a char *. At the same time, change their "short
folder" computation to also use a BUFFER.
Switch to generating the version string during make process rather than
at configure time. This makes it easier to keep the detailed version
string accurate when doing development which doesn't require that the
configure script be rerun.
Kevin McCarthy [Wed, 10 Apr 2019 00:52:14 +0000 (17:52 -0700)]
Convert mutt_expand_fmt() and rfc1524_expand_filename() to BUFFER.
These two functions were tied together and so are converted at the
same time.
Note that rfc1524_expand_filename() had an off-by-one error for the
left hand size of the name template. It was only copying i-1 instead
of the i characters before %s.
Kevin McCarthy [Fri, 29 Mar 2019 22:21:02 +0000 (15:21 -0700)]
Change IMAP to try oauthbearer first.
$imap_authenticators says if it is unset, the authenticators from
most-secure to secure will be tried. It makes sense for oauthbearer
to come first, like with POP.
To make this change backwards compatible, it depends on the previous
commit, which changed imap_auth_oauth() to return IMAP_AUTH_UNAVAIL if
oauth is not configured or explictily requested.
Kevin McCarthy [Wed, 13 Mar 2019 04:06:11 +0000 (12:06 +0800)]
Fix incorrect IMAP message purging bug.
Thanks to Ivan Middleton @imiddle for the awesome bug report and
suggested fix.
The bug is most easily generated using Gmail with the $trash variable
set.
Deleted messages are first copied to the $trash folder. If this is
set to "[Gmail]/Trash", then Gmail inteprets the copy as a "delete"
and sends EXPUNGE messages back for the messages.
cmd_parse_expunge() and cmd_parse_vanished() set the hdr->index to
INT_MAX, which subsequently an imap_expunge_mailbox() will use to
remove the messages from the local mailbox.
If we close the mailbox instead of sync it, Mutt will end up executing
the 'Deleted' flag setting before processing the expunge (because
"imap_check_mailbox() -> imap_cmd_finish()' doesn't set check_status
when we are closing). The expunged messages will then be included in
the set of 'Deleted' flags.
Unfortunately, because the messages are sorted by *index* before
msgset generation, an incorrect range of UIDs will be sent, which
could easily include messages that should not be deleted.
This fix is a minimal fix for a stable bug fix excluding
messages with the index set to INT_MAX from all msg sets. Other
things that should be investigated in master are:
- sorting by UID instead of index before msgset generation
- unsetting the 'active' flag in cmd_parse_expunge() and
cmd_parse_vanished() instead of waiting until imap_expunge_mailbox()
to do so.
Kevin McCarthy [Sun, 10 Mar 2019 02:03:52 +0000 (10:03 +0800)]
Improve imap uid seqset hcache buffer usage.
mutt_buffer_increase_size() terminates the buffer, so there is no need
to explicitly check for an empty buffer after the
imap_msn_index_to_uid_seqset() call.
Kevin McCarthy [Sun, 10 Mar 2019 01:58:07 +0000 (09:58 +0800)]
Minor buffer handling code cleanup.
Use mutt_buffer_len() and mutt_buffer_clear() to make the code a bit
clearer. There are still places in the code that manipulate the
buffers directly (pattern.c, for example), but that doesn't mean we
shouldn't abstract the buffer where we can.
Add comments in a couple places where unusual buffer manipulation is
occurring.
Kevin McCarthy [Fri, 8 Mar 2019 11:48:41 +0000 (19:48 +0800)]
Check noconv for mailcap %{charset} send mode expansion.
Improve the previous commit by checking to make sure a->noconv also
isn't set. If noconv is set, we ignore any value a->charset might
have picked up during previous encoding checks.
Kevin McCarthy [Fri, 22 Feb 2019 21:50:52 +0000 (13:50 -0800)]
Add $include_encrypted config to prevent reply-decryption attack.
@jensvoid, in cooperation with Ruhr-Uni Bochum and FH Münster,
Germany, reported a possible "Oracle decryption" attack on various
mail clients. An attacker could include previously encrypted contents
they obtained access to, and include it in a message. Replying
without trimming would include the decrypted contents.
This attack relies on several "ifs", and is more dangerous for clients
that compose HTML mail. However, it is still an issue that an
unwary/busy Mutt user could fall for.
Add a new config $include_encrytped, defaulting off, to reduce the
possibility of the user being unaware of previously encrypted parts in
the reply. Only the main initial encrypted part will be included in
the reply.
Andrey Skvortsov [Thu, 21 Feb 2019 13:37:05 +0000 (16:37 +0300)]
Fix truncation of long filenames in attachments.
Currently mutt truncates long filenames in attachments and doesn't
take into account UTF-8 character size. If filename is truncated in
the middle of multi-byte UTF-8 character (last character is bad),
then some mail clients assume whole attachment name bad and don't
display its name (use 'Noname' instead).
Filenames can be up to 255 *characters* long depending on used
filesystem. ReiserFS, NFTS, FAT, APFS and some other supports up to
255 characters.
In the worst case 255 characters in UTF-8 will take 255*4 = 1020
bytes. Every non-ascii byte in the filename will be encoded using 3
bytes (for example, %8D).
So 'Content-Disposition' will take in the worst case up to: 1020*3 =
3060 bytes. Therefore even LONG_STRING (1024) isn't enough.
Kevin McCarthy [Sat, 2 Feb 2019 23:03:03 +0000 (15:03 -0800)]
Separate out op variable in the browser.
The i variable is used in several places and scopes as a temporary
index variable, but is also used to record the current operation.
Separate them out to make the code less confusing.
Corey Minyard [Thu, 31 Jan 2019 23:57:57 +0000 (17:57 -0600)]
Allow descending into maildir and mh directories in file browser
Some (maybe most) IMAP mail systems allow folders to be nested inside
folders, so you can have, say, an Inbox with more folders inside it.
However, in the file browser, mutt will only open a maildir/mh
directory as a mailbox, there is no way to get to the child mailboxes.
This change adds a function <descend-directory> that forces mutt to
descend into the directory. It is unbound by default.
Kevin McCarthy [Fri, 25 Jan 2019 02:28:27 +0000 (18:28 -0800)]
Show top-level decoded smime text/plain parts.
Commit 331d9d5a attempted to fix a problem with an attachment having
extension .p7m. The attachment menu tried to decode and failed, and
the part ended up being replaced by a bogus text/plain part.
The problem is that crypt_smime_decrypt_mime() returns a text/plain
part if the decode fails, meaning we can't distinguish failure from
success in this case.
As a compromise, only use a text/plain resulting from a single
top-level application_smime part. This will allow for the case of an
text/plain encoded email, but won't end up hiding attachments that
were not decoded.
Kevin McCarthy [Thu, 24 Jan 2019 23:19:36 +0000 (15:19 -0800)]
Simplify nested smime handling in the attachment menu.
Since changeset 2fd6f99b allows nested encryption handling, there is
no need to deal with the nesting directly. Instead, just recursive as
with other nested handling.
Kevin McCarthy [Thu, 24 Jan 2019 22:15:33 +0000 (14:15 -0800)]
Improve attachment menu for s/mime parts. (closes #113)
Don't prompt for passphrase or getkeys, or set the ENCRYPT flag, for
OPAQUE types.
Don't recurse on "text" output from decrypt_mime(). There is no
reason to recurse on a text type. Additionally, the
mutt_read_mime_header() will return an empty text type even if the
decode doesn't generate mime output. In those cases, we want to show
the original attachment.
Kevin McCarthy [Tue, 22 Jan 2019 03:43:08 +0000 (19:43 -0800)]
Fix tunnels to also retry and write full buffer.
Change the tunnel_socket_read() and tunnel_socket_write() as the raw
sockets were adjusted in the previous commit. Retry on EINTR, and
complete a full write so all the implementations have the same behavior.
Kevin McCarthy [Mon, 21 Jan 2019 23:19:08 +0000 (15:19 -0800)]
Fix raw socket read/write to follow expected behavior.
The mutt_sasl.c code expects conn_write() to write the entire buffer.
This is inconsistent with mutt_socket.c, but since other conn_write()
implementations guarantee this, change raw_socket_write() to do so too
for now.
Also, update reading and writing to loop on EINTR, as gnutls does.
They won't return EAGAIN or EWOULDBLOCK because we don't mark sockets
as non-blocking.
Kevin McCarthy [Mon, 21 Jan 2019 19:56:04 +0000 (11:56 -0800)]
Fix gnutls tls_socket_write() to properly retry.
Retry on GNUTLS_E_AGAIN and GNUTLS_E_INTERRUPTED. This prevents an
aborted send due to a SIGWINCH, for instance.
Change tls_socket_read() to follow the same flow. Don't bother
checking gnutls_error_is_fatal() because return codes besides AGAIN
and INTERRUPTED end up closing the connection regardless. (We don't
handle handshakes and negotations during send/receive).
Kevin McCarthy [Thu, 10 Jan 2019 17:56:41 +0000 (09:56 -0800)]
Wrap ssl init calls for LibreSSL too.
It looks like LibreSSL does not perform automatic initialization of
the library and error strings.
Since LibreSSL defines OPENSSL_VERSION_NUMBER as a "version 2",
add a check if LIBRESSL_VERSION_NUMBER is defined and call the
initialization functions for that case.
Fabian Groffen [Thu, 10 Jan 2019 15:03:02 +0000 (16:03 +0100)]
mx_open_mailbox: provide output buffer to realpath(3)
Starting with POSIX.1.2008 resolved_path can be NULL.
Systems implementing a standard before that crash. Example of such
system is Mac OS X 10.5, the last version running on PowerPC hardware.
Since this is the only occurrance of the realpath(3) function in Mutt,
instead of wrapping it, just adjust this invocation.
Eike Rathke [Sat, 5 Jan 2019 21:54:26 +0000 (22:54 +0100)]
Fix mkdtemp() random signedness
time_t return of time() may be signed 32-bit and in that case
probably will roll over in the year 2038 and yield a negative
value; signedness was propagated in the XOR operation to the
'value' and then 'v' variables. The 'v % 62' operation then would
had resulted in a negative value and LETTER[v%62] would had
accessed an arbitrary data location.
The same could had happened if the static long 'value' variable
after a very long run time contained a sufficiently large value to
which the time^pid value added resulted in a wrap / roll-over to a
negative value.
Using unsigned long types for 'value' and 'v' and casting time_t
to unsigned long cures all this.