Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upstream changes #1638

Merged
merged 21 commits into from Apr 9, 2019
Merged

upstream changes #1638

merged 21 commits into from Apr 9, 2019

Conversation

flatcap
Copy link
Member

@flatcap flatcap commented Apr 6, 2019

Most of the outstanding upstream changes.

@flatcap flatcap self-assigned this Apr 6, 2019
@flatcap flatcap mentioned this pull request Apr 8, 2019
@Austin-Ray Austin-Ray self-requested a review April 8, 2019 23:50
Copy link
Contributor

@Austin-Ray Austin-Ray left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading over these, I see nothing glaringly wrong with these commits. I'd like an extra pair of eyes to review the GPG commits since that is not my area of expertise.

kevin8t8 and others added 21 commits April 9, 2019 12:54
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.

Co-authored-by: Richard Russon <rich@flatcap.org>
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.

Co-authored-by: Richard Russon <rich@flatcap.org>
@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.

Co-authored-by: Richard Russon <rich@flatcap.org>
For gpgme >= 1.11.0, use gpgme_op_encrypt_ext() and
gpgme_op_encrypt_sign_ext() to specify recipients as a string.

This allows '!' to specify forcing a subkey, as is the case in classic
gpg and from the command line.

Remove the '!' "force valid" usage for the newer version.

Co-authored-by: Richard Russon <rich@flatcap.org>
Use the current charset of the file for the parameter, since the file
hasn't been converted yet.

Co-authored-by: Richard Russon <rich@flatcap.org>
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.

Co-authored-by: Richard Russon <rich@flatcap.org>
Make it clearer what BODY->charset is used for, and why we are
checking for !noconv during mailcap charset parameter expansion.

Co-authored-by: Richard Russon <rich@flatcap.org>
This provides a brief overview of the steps during message
composition, and shows when the various hooks are executed.

Co-authored-by: Richard Russon <rich@flatcap.org>
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.

Co-authored-by: Richard Russon <rich@flatcap.org>
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.

Co-authored-by: Richard Russon <rich@flatcap.org>
Pass the correct buffer size through, so the strfcpy added in the next
commit doesn't write past the end of the buffer.

Co-authored-by: Richard Russon <rich@flatcap.org>
TODO: '@' expansion using mutt_default_save() is still using a fixed size
string parameter.

Convert imap_expand_path() and mutt_rx_sanitize_string() to use
BUFFERS instead.

Add url_ciss_tobuffer().

Co-authored-by: Richard Russon <rich@flatcap.org>
Create _mutt_buffer_expand_path() with the rx argument.

Use mutt_b2s() instead of derefencing buffer->data in
mutt_buffer_expand_path().  The p->data uses were safe, but the
src->data was potentially not.

Co-authored-by: Richard Russon <rich@flatcap.org>
Co-authored-by: Richard Russon <rich@flatcap.org>
Co-authored-by: Richard Russon <rich@flatcap.org>
Co-authored-by: Richard Russon <rich@flatcap.org>
Don't report an error unless they explicitly put "oauthbearer" in the
authenticator list or configured the oauth_refresh_command.

Co-authored-by: Richard Russon <rich@flatcap.org>
$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.

Co-authored-by: Richard Russon <rich@flatcap.org>
Commit 285baf9a improved FLAGS parsing such that "spurious" FLAGS
updates won't cause a mailbox reopen.

Remove the h->active=0 hack because it isn't needed now and makes
reasoning about deletes, purges, and message set generation more
difficult.

Co-authored-by: Richard Russon <rich@flatcap.org>
Co-authored-by: Richard Russon <rich@flatcap.org>
Co-authored-by: Richard Russon <rich@flatcap.org>
@flatcap flatcap merged commit 730de99 into master Apr 9, 2019
@flatcap flatcap deleted the devel/upstream branch April 9, 2019 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants