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
upstream changes #1638
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
Austin-Ray
approved these changes
Apr 8, 2019
There was a problem hiding this 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.
gahr
approved these changes
Apr 9, 2019
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the outstanding upstream changes.