Re: Compatibility with mailx aliases
On Sun, Jun 23, 2024 at 08:44:44AM +0200, Rene Kita wrote: On Sun, Jun 23, 2024 at 01:53:21PM +0800, Kevin J. McCarthy wrote: On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote: > MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from > the header: > #define MUTT_TOKEN_QUOTE (1<<3) /* don't interpret quotes */ > > AFAIU, this should not have undesired side effects. But I have never > read this part of the code before, I might be wrong. This will break aliases such as alias kmtest "McCarthy, Kevin" The double quotes are stripped out of the returned token without MUTT_TOKEN_QUOTE. Yes, that's the whole idea, isn't it? As said somewhere up thread, you'll need to use single quotes in such a case. alias kmtest '"McCarthy, Kevin" ' This is the same behavior as mailx shows and breaks current mutt behavior. That's why it should be an option. Okay. I saw that but thought you had later concluded there were no side effects. My mistake :). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Compatibility with mailx aliases
On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote: MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from the header: #define MUTT_TOKEN_QUOTE (1<<3) /* don't interpret quotes */ AFAIU, this should not have undesired side effects. But I have never read this part of the code before, I might be wrong. This will break aliases such as alias kmtest "McCarthy, Kevin" The double quotes are stripped out of the returned token without MUTT_TOKEN_QUOTE. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] crypt-gpgme.c: Fix NULL dereference
On Fri, Apr 19, 2024 at 10:30:54PM +0200, Alejandro Colomar wrote:
We applied this patch to neomutt(1) a few months ago. See the link in
the commit message for more details. It's a cherry-pick of neomutt's
commit bd9ceb2a6442b966 ("ncrypt/crypt_gpgme.c: Fix NULL dereference").
Thank you for forwarding the commit. I'll push it up today.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: Message security; protected header fields
On Fri, Apr 19, 2024 at 05:07:17PM -0400, Derek Martin wrote: On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote: On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote: > However, saying that mutt adds those headers by accident or as a bug seems a > bit uninformed. Fair enough. But--and I s'pose I may have just missed it--I don't recall seeing any discussion of this feature on this list. Learning of such things is precisely why I'm on this list, so... I'm not sure whether it's better (from my perspective) that I missed it, or if it never happened. =8^) That's fair enough back. I don't think I engaged the list in discussion of the change. :^) What I did do was a minimal implementation of the spec at the time, so that Mutt could read messages from other clients that started sending with a hidden Subject header, for interoperability. Writing was not enabled by default, but when enabled, it did send most/all of the spec listed headers (at the time), again for interoperability. Doing "things" with other headers or even displaying them would open a big can of worms, so I kept the implementation minimal on purpose. I don't have an opinion on the future direction Mutt takes here. It wouldn't be hard to rip out the existing implementation, or to extend it. However, I'll just remind everyone (again) that I'm definitely on my way out, completely, of Mutt development. I stopped being a maintainer a couple years ago, and my time available just keeps getting less and less. :-( I just don't have the time to participate anymore, not to mention review patches. If others really want the project to continue, it would be good for someone(s) to start picking up the reins. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Message security; protected header fields
On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote: However, I'd like to point out that mutt added basic support for Protected Headers in the 2.0 release, following the Autocrypt project Ah, sorry, it was originally added in the 1.12 release (5/2019)! The 2.0 release added additional headers to the list and made some other tweeks. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Message security; protected header fields
On Fri, Apr 19, 2024 at 01:59:57AM +0200, Alejandro Colomar wrote: BTW, now that I remember, while developing these things for neomutt(1), I found that mutt(1) has a bug (?) by which it does actually protect some header fields precisely in the way that I implemented them in neomutt(1), with the difference that mutt(1) does it on accident. As Derek mentioned, mutt is in maintenance mode. I don't have much, if any, time available to address issues except for genuine crashes or vulnerabilities. However, I'd like to point out that mutt added basic support for Protected Headers in the 2.0 release, following the Autocrypt project spec at the time <https://github.com/autocrypt/protected-headers>. Since then, undoubtedly, they've advanced the proposed spec, but I haven't followed it. However, saying that mutt adds those headers by accident or as a bug seems a bit uninformed. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: mutt on OpenBSD
On Tue, Apr 25, 2023 at 01:12:18PM +0100, ckeader via Mutt-dev wrote: And this is the scenario where the certificate exists in the file [2023-04-25 12:15:35] Looking up disroot.org... [2023-04-25 12:15:35] Connecting to disroot.org... [2023-04-25 12:15:35] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:35] SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed Thank you for the heads-up about the problem. Strange, it is successfully loading the certificates file, but then after calling SSL_connect() it doesn't even get to the point of calling mutt's ssl_verify_callback() function. It just blows up and returns an internal error. [2023-04-25 12:15:36] Connected to disroot.org:993 on fd=-1 [2023-04-25 12:15:37] mutt_index_menu[831]: Got op 102 [2023-04-25 12:15:37] mutt_buffer_pool_free: 15 of 15 returned to pool It seems libressl has had problems with certificate chains before. Just out of curiosity, what happens if you set $ssl_verify_partial_chains? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: PLAIN auth mechanism fails with outlook.office365.com imap server
On Thu, Apr 13, 2023 at 01:59:56PM +0200, Sébastien Hinderer wrote: Am I correct in trusting the sysadmin that IMAP support is indeed enabled for this account? IMAP does appear to be enabled, since Mutt is able to connect to the IMAP port and try to authenticate. If the problem would be an incorrect password, would that be written explicitly in the debug output, or would I get this error message and no more details? No, Mutt has no way to tell if the password is correct or not. Mutt knows as much as you see in the debug output: the server replied with "NO AUTHENTICATE failed.", without giving an explicit reason. Note you can check the authentication value sent in the debug log by base64 decoding it. For PLAIN it should be $imap_user + '\0' + $imap_login + '\0' + $imap_pass. (The default of value of $imap_login is $imap_user - so there is no need to set it separately unless there is a need for them to be different). It could be that PLAIN is advertised, but not actually working. That would be something to ask the admin about too. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH 0/2] Use base64 URL safe alphabet for message id generation.
On Sat, Mar 04, 2023 at 06:15:24PM -0800, Kevin J. McCarthy wrote: I'll take another look tomorrow and if I still don't see any issues will push to stable for a (well overdue) 2.2.10 release in the next week or so. I've merged this into stable. Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH 0/2] Use base64 URL safe alphabet for message id generation.
On Sat, Mar 04, 2023 at 06:33:33PM +0100, Sebastian Andrzej Siewior wrote: #2 of this mini series uses the safe dictionary for base64 encoding to use for message-id generation. This bothered me for a while and then I stumbled uppon issie #400 so it appears to not be just me. #1 is rather unimportant but allows to decode this safe URL base64 encoded strings if ever needed. Thank you Sebastian, and again my apologies to everyone for basically ignoring #400. These patches look okay to me. I've made a couple small indentation and spacing fixes to be in line with Mutt code, but otherwise they seem fine. I'll take another look tomorrow and if I still don't see any issues will push to stable for a (well overdue) 2.2.10 release in the next week or so. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] mutt_oauth2: Print access token request message
On Mon, Dec 19, 2022 at 06:53:43PM -0800, Cline, Wade wrote: 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. Applied. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH v3] Add socket send/receive timeout options
On Thu, Dec 01, 2022 at 04:54:21PM -0800, Matthew Sotoudeh via Mutt-dev wrote: 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. Signed-off-by: Matthew Sotoudeh --- Thanks all for the comments! Thank you Matthew. It's been a busy week, but I'll get this tested and committed this weekend! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH v2] Add a receive_timeout option for sockets
On Wed, Nov 30, 2022 at 08:03:13AM +0100, Petr Pisar wrote: V Tue, Nov 29, 2022 at 11:28:29AM -0800, Kevin J. McCarthy napsal(a): If that's not always the case then we can add a SNDTIMEO too. Also an option. Though, I cannot see a reason why somebody wanted a different timeout for reading and for writing. Adding SNDTIMEO later would require adding a new configuration option. I wanted to prevent from proliferating them. I'm fine with adding configuration options if they make sense. If it's generally agreed that _no one_ would want to have a different RCVTIMEO and SNDTIMEO, then I'm also fine with just $socket_timeout. But for low level socket timeout tweaking, I'm not convinced someone eventually won't come and ask for separate values, for some reason or another. The $imap_poll_timeout code works in that way, at least, sending a NOOP and polling those seconds for a response. Have you considered another network-accessed mail boxes, like POP3? There is no general application-level timeout for them in Mutt. imap_poll_timeout is only for IMAP, isn't? Also I think that imap_poll_timeout applies after read()/write() returns. If one of them blocks, imap_poll_timeout won't help. I think this is getting off-topic for this thread, unless I'm misunderstanding. The IMAP timeout code does a write() (usually just "NOOP") followed by a poll(). As you say it's not bullet-proof but does help in a lot of cases, combined with the auto-reconnect code. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH v2] Add a receive_timeout option for sockets
On Tue, Nov 29, 2022 at 11:36:59AM -0800, Matthew Sotoudeh via Mutt-dev wrote: Thanks for pointing that out ! To second Kevin's comments below, I personally didn't find a SNDTIMEO necessary. Also worth noting that, at least in my case, large writes (sending email, etc.) happen while I'm sitting down, so a much more stable network connection vs., e.g., background downloading of new mail. Happy to add a SO_SNDTIMEO while we're at it just in case/for consistency, though, if people prefer that. Since setsockopt() itself separates the timeout types, I wouldn't be opposed to adding both a $socket_receive_timeout and $socket_send_timeout config setting. That way, if for some reason a person wanted or needed to tweak them separately, they can. These are definitely "advanced tweaking" options, so I think it's okay to separate them. But if we add both I like having a common "socket_" prefix so they are grouped in the manual, and it's immediately clear they are referring to socket settings. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH v2] Add a receive_timeout option for sockets
On Tue, Nov 29, 2022 at 02:19:26PM +0100, Oswald Buddenhagen wrote: On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev wrote: + ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after + ** this many seconds. A zero (default) or negative value causes Mutt to wait + ** indefinitely for the read to complete. have you checked how this plays along with imap IDLE? Thanks Oswald. I'll take a closer look before committing, but I don't think it should have a particular effect, at least for Mutt's implementation. Mutt sends IDLE, polls the socket for up to $imap_poll_timeout, and then reads looking for the "+" response. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH v2] Add a receive_timeout option for sockets
On Tue, Nov 29, 2022 at 09:44:25AM +0100, Petr Pisar wrote: If a network is unreliable, you will have similar problem with writing to the TCP socket. I think it would be better to rename the option to socket_timeout and use the same value for both setsockopt(, SO_RCVTIMEO, ) and setsockopt(, SO_SNDTIMEO, ). Thanks for your feedback Petr. In my experience, I've found that writing (small amounts) to a "hung" socket doesn't seem to be a problem - the computer buffers it or something; it's trying to read the response back that hangs. The $imap_poll_timeout code works in that way, at least, sending a NOOP and polling those seconds for a response. If that's not always the case then we can add a SNDTIMEO too. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Updated: add a receive_timeout option for sockets
On Mon, Nov 28, 2022 at 07:45:00PM -0600, David Vernet wrote:
On Mon, Nov 28, 2022 at 04:14:10PM -0800, Matthew Sotoudeh via Mutt-dev wrote:
Per feedback from Kevin & David (thanks!), moved the timeout code into
socket_connect and updated the description to be more descriptive and
more closely match the existing connect_timeout.
I'm not sure how the mutt review process usually works (Kevin can chime
in here to correct me if it's different around here), but in Linux
kernel reviews, the differences between patch revisions is put below the
--- at the sign off. See [0] for more information. If you put it here,
it is like you are proposing to include it in the commit summary.
Also, follow-on iterations of a patch should have the version specified
(e.g. -v 2 for git format-patch), and be sent as a separate email thread
rather than being sent as a reply to an earlier thread. Again, Kevin can
tell me if things are different for mutt reviews.
We're not so formal here, because the volume is quite low, especially as
I've eased down development.
A lot of our review has also moved to gitlab, although I like to have
things reviewed here that might be interesting to a wider audience.
There is some open question about where exactly in socket_connect to put
the timeout code. Currently I put it after the basic input validation
but it may be slightly better to wait until the socket is actually
opened? But being a global option anyways, I don't think it can hurt
FWIW, I would do it before the socket is opened.
Agree.
diff --git a/mutt_socket.c b/mutt_socket.c
index 3e192072..4e1b7889 100644
--- a/mutt_socket.c
+++ b/mutt_socket.c
@@ -407,6 +407,12 @@ static int socket_connect (int fd, struct sockaddr* sa)
return -1;
}
+ if (ReceiveTimeout > 0)
+ {
+struct timeval tv = { ReceiveTimeout, 0 };
+setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char *), sizeof(tv));
+ }
socket_connect() doesn't seem super concerned with checking return
values elsewhere (e.g. in sigaction() calls), but IMO there's no reason
for us to not add them for new code. Could you please check the return
value of setsockopt() here? Not sure if it's preferable to return that
value to the caller, or instead just print a dprint() message if it
fails and continue on. Given that we don't even propagate the error for
connect(), I expect the latter is preferable. Kevin, thoughts?
The connect error looks to be returned and used in raw_socket_open().
But for setsockopt, I agree just adding a dprint and continuing should
be okay.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] Add a receive_timeout option for sockets
On Sat, Nov 26, 2022 at 11:38:24AM -0800, Matthew Sotoudeh via Mutt-dev wrote: 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 receive_timeout option appears to resolve the issue for me, thought others may find it useful. Thanks for sending the patch. As long as it remains disabled by default, I don't have a problem adding this option - especially if it did solve your problem. Does anyone else have an opinion? There are actually two calls to socket_connect() in raw_socket_open(). What if we moved the change inside of socket_connect() instead? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Account for Timeout <= 0 for sending IMAP NOOP cmd
On Wed, Oct 19, 2022 at 09:42:55PM -0500, David Vernet wrote: On Wed, Oct 19, 2022 at 04:20:22PM -0700, Kevin J. McCarthy wrote: That's fine, or I'll be happy to touch it up myself after this is resolved. Whatever will cause less churn / work for you is fine with me. I wouldn't mind throwing my name on a mutt commit, but if it will cause less back and forth for you to just write it how you'd like that's fine as well. If you do, please feel free to ping me for a review. In that case, please do feel free to update the documentation too. It wasn't my intention to make it harder for you to have your name on these fixes and updates. :-) It also may have been more correct to set i to INT_MAX in km_dokey() for the 0/negative case. We could do that, but I'd argue we have the reverse problem now: the behavior has been as-is for 20+ years. Even though the doc's say it doesn't timeout, it does, and it does end up checking current mailbox/buffy about once a minute. Understood, being a Linux kernel contributor I'm used to this constraint. We must reward our loyal users with the expectation that we won't pull the rug out from under them, even when "fixing" a bug to match what's documented :-) It is what it is, and honestly, fixing the documentation to describe the behavior and its implications is probably sufficient given the available workaround of setting a large timeout anyways. Perhaps adding a comment in the code is warranted as well. Sounds fine, to at least acknowledge that precedence is overriding a more "correct" implementation. I still think it would be better to just change the $timeout doc to say a 0/negative value will default to 60, and just change imap_check_mailbox() to do the same, to make minimal behavior changes right now. If you feel this is the best / lightest touch, I'm happy to send out a patch that does it. For my own clarification though, what would we gain from doing this if keepalive is also sending the noops? Wouldn't this just result in the same behavior, expect that we may even be sending multiple, redundant NOOPs? I've been thinking about this quite a bit, and honestly I've gone back and forth. My strongest resistance was worrying about regressions: - At first I forgot about the keepalive NOOPs being sent, but with those at least the connection won't be closed and will at least occasionally guarantee updates/expunges are received. - The only other non-force imap_check_mailbox() is in imap_sync_mailbox(). But since $timeout can also be set very high I don't see how making "0" skip the NOOP should cause a problem here. - Then there are the (IMAP using) folks who currently have $timeout set to 0. If there is any latency they've probably given up on that by now, but perhaps some with a local IMAP server have it set. Right now, they are seeing "immediate" updates whenever they scroll around. Changing to 60 will slow this down, but probably not as noticeably as waiting for $imap_keepalive. The biggest problem is that Mutt has obfuscated the way IMAP current mailbox polling works, using a variable ($timeout) that it perhaps shouldn't have, without documenting it. Either way we ought to change this for <=0, and so it will be a "change in behavior". After thinking it through, I've changed my mind and am not opposed to having it skip the NOOP in imap_check_mailbox(). I think making "a change" is justifiable given the horrible current behavior, and given that we document the change and reasoning well. However, let's give a few days to see if anyone else on the list has feedback. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Account for Timeout <= 0 for sending IMAP NOOP cmd
On Wed, Oct 19, 2022 at 02:16:12PM -0500, David Vernet wrote: On Wed, Oct 19, 2022 at 10:47:26AM -0700, Kevin J. McCarthy wrote: The documentation should be fixed for that. Ack, thanks for clarifying. I'm happy to send an update to the documentation as part of this patch set as well if you'd like. That's fine, or I'll be happy to touch it up myself after this is resolved. Also, while perusing the code I noticed that the first ImapKeepalive in km_dokey() is redundant as we hav an if check for ImapKeepalive above it: while (ImapKeepalive && ImapKeepalive < i) So I can also include a small cleanup for that as well, assuming I'm not wrong that it's constant / static for the runtime of the program. I don't think it will change within the loop. But right now, Mutt is in bug-fix mode, so I'd like to keep fixes targeted towards actual bug fixes. It looks redundant to me too, but unless there is a problem occurring I'd prefer to just leave as-is. I agree imap_check_mailbox() should be fixed so it isn't blasting NOOPs all the time too. But the side effect of your patch would be to almost never send NOOPs, which would make Mutt very slow to notice new mail (unless $imap_idle is in use). Err sorry... I did forget that the keepalive was sending NOOPs too, and the main loop mx_check_mailbox() will pick up the new mail when REOPEN is set. So I retract the above. :) What if it did the same thing as km_dokey(), changing <=0 to 60? Hmm, my personal opinion is that silently changing the timeout to a higher value may be unexpected / unwanted for users that really want to avoid ever pinging the IMAP server so as to avoid latencies. I think this expectation is outside of the scope of $timeout too. $timeout is really about how long to wait at the menu for input before giving up and "doing things" like checking mail or buffy. But (as documented) it doesn't deal with behavior once outside the menu prompt. I don't think setting it to 0 to avoid pinging the IMAP server, even when *outside* the prompt, is expected by users at this point. I'm guessing Timeout was added to imap_check_mailbox() to avoid sending NOOP's constantly when scrolling or such, as a kind of hack. This does behave badly when $timeout is 0 (or negative). Perhaps there should have been another variable added originally. It also may have been more correct to set i to INT_MAX in km_dokey() for the 0/negative case. We could do that, but I'd argue we have the reverse problem now: the behavior has been as-is for 20+ years. Even though the doc's say it doesn't timeout, it does, and it does end up checking current mailbox/buffy about once a minute. I still think it would be better to just change the $timeout doc to say a 0/negative value will default to 60, and just change imap_check_mailbox() to do the same, to make minimal behavior changes right now. Perhaps just setting $timeout to 32000 would accomplish what you want better? W.r.t. us bending the rules a bit for IMAP keepalive, IMO it feels like IMAP keepalive is slightly different than checking for new mail in that IMAP keepalive prevents annoying / long latencies that would result from having to reauthenticate if the IMAP server dropped your connection due to inactivity from _not_ polling for new mail. In other words, I think it actually enables this specific use case of allowing the user to not ping the IMAP server if they don't want to, by ensuring the connection stays alive on the user's behalf according to the IMAP RFC. I think your understanding of keepalive is correct (although, again, the $timeout documentation needs to be fixed here, since km_dokey() is checking $imap_keepalive). However, again, I don't agree this is to enable the user to avoid pinging the IMAP server if they don't want to (by setting $timeout to 0). I'm out of time today, but I'll try to look through this part of the code again tomorrow to see if I'm missing or misunderstanding things. (It's been a while since I've gone through this area). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Account for Timeout <= 0 for sending IMAP NOOP cmd
Hi David, Thanks for the patch. On Wed, Oct 19, 2022 at 12:01:36PM -0500, David Vernet wrote: In imap_check_mailbox(), there is an if clause where we potentially poll IMAP with a NOOP command. This can be invoked on many ops, including if we e.g. move to the next message on the index. According to http://www.mutt.org/doc/manual/#timeout, the expected behavior of Timeout is that a timeout value of <= 0 will cause Mutt to never time out. It looks like "never timing out" used to be the case, but was slowly changed (e.g. commit 2fee61e1). Now, km_dokey() will change <=0 to 60, to make sure IMAP keepalive's run. The documentation should be fixed for that. I agree imap_check_mailbox() should be fixed so it isn't blasting NOOPs all the time too. But the side effect of your patch would be to almost never send NOOPs, which would make Mutt very slow to notice new mail (unless $imap_idle is in use). What if it did the same thing as km_dokey(), changing <=0 to 60? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Avoid falsely uncollapsing threads for old messages
On Wed, Sep 14, 2022 at 02:53:27PM +0200, Magnus Groß wrote: On Wed, Sep 14, 2022 at 12:23:44PM +0800, Kevin J. McCarthy wrote: For that case, Mutt is uncollapsing every thread, passing in the parent message of each thread. But surely it is not intended to uncollapse every thread, just because I accidentally happen to reopen the mailbox because I saved a copy of an outgoing message in the current mailbox? A reopen typically occurs because of an external modification, such as conflicting flags or a deletion. Perhaps something in your setup is triggering this somehow. If you are using IMAP, you might check if there is an auto-expunge setting and disable that, for instance. Otherwise you can try to track down why mx_check_mailbox() is returning MUTT_REOPENED. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New option crypt_batchsign
On Thu, Jul 28, 2022 at 12:57:58PM +0200, Werner Koch wrote:
Mutt is very useful as a tool for sending unattended mails. In
particular the easy way to add attachments is very useful, for example
to send release notes to customers. However, it is by design not
possible to sign such mails. The reason for this might be that for
signing you need to unlock your key and without caching the passphrase
in gpg-agent this does make much sense.
The proposed new option allows to overcome this design decision with
less risk of any regression.
I am using this patch for more than a half year now and have
successfully sent thousands of signed mails with attachments using a
straightforward script.
Please consider to add this option to Mutt.
Thanks Werner. I have comments inline below. Just as a reminder, I'm
only maintaining stable releases at this point, but the option is
interesting and deserves comments. :-)
diff --git a/init.h b/init.h
index fa1e3b7d..bc80e3dd 100644
--- a/init.h
+++ b/init.h
@@ -797,6 +797,13 @@ struct option_t MuttVars[] = {
{ "crypt_autosign", DT_BOOL, R_NONE, {.l=OPTCRYPTAUTOSIGN}, {.l=0} },
/*
** .pp
Documentation needs to be after the option, to generate the manual
properly.
+ ** This variable controls whether or not mutt may automatically
"may" or "will"? The documentation makes it sound like Mutt will
consider it, subject to other options, such as $crypt_autosign.
+ ** PGP signing messages even in batch mode. See also
The code below looks like it will turn on signing for S/MIME too. In
classic mode (for PGP and S/MIME) this could cause problems.
I think it would be good to check explicitly that they are either using
GPGME, or else PGP with $pgp_use_gpg_agent set. This may be a bit
tricky, since Mutt only checks $crypt_use_gpgme at startup to bind the
glue functions.
--- a/send.c
+++ b/send.c
@@ -2128,6 +2128,7 @@ static int send_message_resume_first_edit (SEND_CONTEXT
*sctx)
{
int rv = -1;
int killfrom = 0;
+ int sendbatch_flag;
if (sctx->flags & SENDMAILX)
{
@@ -2263,14 +2264,18 @@ static int send_message_resume_first_edit (SEND_CONTEXT
*sctx)
* 3) we are resending a message
* 4) we are recalling a postponed message (don't override the user's saved
settings)
* 5) we are in mailx mode
- * 6) we are in batch mode
+ * 6) we are in batch mode (unless crypt_batchsign is set)
*
* This is done after allowing the user to edit the message so that security
* settings can be configured with send2-hook and $edit_headers.
*/
- if (WithCrypto && (sctx->msg->security == 0) && !(sctx->flags & (SENDBATCH |
SENDMAILX | SENDPOSTPONED | SENDRESEND)))
+ sendbatch_flag = option (OPTCRYPTBATCHSIGN)? 0 : SENDBATCH;
+ if (WithCrypto && (sctx->msg->security == 0)
+ && !(sctx->flags & (sendbatch_flag | SENDMAILX | SENDPOSTPONED |
SENDRESEND)))
{
-if (
+if (option (OPTCRYPTBATCHSIGN))
+ sctx->msg->security |= SIGN;
So again, this logic needs to be different if $crypt_batchsign defers to
$crypt_autosign to actually enable signing.
Overall I'm a little nervous how the Mutt code behaves with respect to
quadoptions and prompts and such. I guess you've tested it quite a bit,
but I'd still want to look through the code throroughly, since up to
this point Mutt assumed crypto was always interactive if needed.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] Make optional for query_command
On Thu, Jul 07, 2022 at 10:41:39AM -0700, Kevin J. McCarthy wrote: On Thu, Jul 07, 2022 at 04:00:09PM +0200, Magnus Groß wrote: On Fri, Mar 04, 2022 at 06:16:28PM -0800, Kevin J. McCarthy wrote: A slightly more intrusive patch using strchr() might be better (untested, just below). This also removes '\n' from the delim list, since that's a remnant from when fgets() was used. Could you please apply this patch? I have been using it for a month now and it seems to be stable and works great! Thanks. This is currently applied in my branch `kevin/main`. Due to the change in behavior, the patch is not without risk, so I'm cautious about applying it to stable. What do others on the list think? If others think it's worth it to fix the behavior, I will apply it to stable for the 2.6.7 release (which I need to get that out in the next week or so). It looks like there aren't any strong opinions on this. So, I think I'll take the risk in this case and add it to 2.2.7, with the caveat that if it breaks anyone's $query_command I'll revert it. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Make optional for query_command
On Thu, Jul 07, 2022 at 04:00:09PM +0200, Magnus Groß wrote: On Fri, Mar 04, 2022 at 06:16:28PM -0800, Kevin J. McCarthy wrote: A slightly more intrusive patch using strchr() might be better (untested, just below). This also removes '\n' from the delim list, since that's a remnant from when fgets() was used. Could you please apply this patch? I have been using it for a month now and it seems to be stable and works great! Thanks. This is currently applied in my branch `kevin/main`. Due to the change in behavior, the patch is not without risk, so I'm cautious about applying it to stable. What do others on the list think? If others think it's worth it to fix the behavior, I will apply it to stable for the 2.6.7 release (which I need to get that out in the next week or so). Thanks, -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Forwarding inconsistency
On Fri, Jun 10, 2022 at 10:51:42PM +0100, ckeader wrote: Thank you, Kevin! Yes, the patch works for this specific case, and I haven't tested it any further. Great. Thanks for testing it out. I've been taking a closer look, and I believe that fix is the correct one - it looks like it was just a mistake in the message attachment function. The correct behavior is found, for instance, in the set_copy_flags() function. I'll commit the fix to stable this weekend. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Forwarding inconsistency
On Thu, Jun 09, 2022 at 09:05:47AM -0700, Kevin J. McCarthy wrote:
I won't have time to investigate until this weekend, but it looks like
this is an issue with encrypted S/MIME. The forward handler is always
specifying to decode.
There *is* code to properly decrypt-only, but I need to take a closer
look to see if that was an oversight or there are other issues
involved. If not, then this may be an easy fix.
Again, I'll investigate more this weekend. But you are welcome to try
the attached patch and see if it works for you.
Thank you.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
From 9fceb55099b6d4eec53c0ae668fbb631b7b353b2 Mon Sep 17 00:00:00 2001
From: Kevin McCarthy
Date: Thu, 9 Jun 2022 09:22:03 -0700
Subject: [PATCH] wip: decrypt s/mime when mime-forwarding with
$forward_decrypt
---
sendlib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sendlib.c b/sendlib.c
index b0b94b4f..d9429c2e 100644
--- a/sendlib.c
+++ b/sendlib.c
@@ -1383,8 +1383,8 @@ retry:
else if ((WithCrypto & APPLICATION_SMIME) &&
((mutt_is_application_smime (hdr->content) & SMIMEENCRYPT) == SMIMEENCRYPT))
{
- chflags |= CH_MIME | CH_TXTPLAIN;
- cmflags = MUTT_CM_DECODE | MUTT_CM_CHARCONV;
+ chflags |= CH_MIME | CH_NONEWLINE;
+ cmflags = MUTT_CM_DECODE_SMIME;
pgp &= ~SMIMEENCRYPT;
}
}
--
2.35.1
signature.asc
Description: PGP signature
Re: Forwarding inconsistency
On Thu, Jun 09, 2022 at 10:19:24AM +0100, ckeader wrote: I've come across what I believe is an inconsistency in message forwarding. It seems that encrypted and non-encrypted messages are treated differently. When I forward a full message as "message/rfc822", I expect the same result, regardless of encryption status. Thank you for the bug report. I won't have time to investigate until this weekend, but it looks like this is an issue with encrypted S/MIME. The forward handler is always specifying to decode. There *is* code to properly decrypt-only, but I need to take a closer look to see if that was an oversight or there are other issues involved. If not, then this may be an easy fix. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Add error when $sendmail has shell metachars
On Tue, May 24, 2022 at 09:58:08AM -0700, Kevin J. McCarthy wrote:
On Fri, May 20, 2022 at 05:56:58PM +1000, raf wrote:
+#define SHELL_NON_SPACE_META_CHARACTERS "|&;()<>[]{}$`'~\"\\*?"
+ if (Sendmail[strcspn(Sendmail, SHELL_NON_SPACE_META_CHARACTERS)] != '\0')
+ {
+mutt_error(_("$sendmail cannot contain shell meta-characters."));
+return -1;
+ }
Also, taking a closer look at the patch.
* strcspn() matches an initial prefix. You might want to use
strpbrk() instead.
Err... sorry my mistake! The strcspn() usage in your patch is correct -
my brain was confused. :-/
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] Add error when $sendmail has shell metachars
On Fri, May 20, 2022 at 05:56:58PM +1000, raf wrote:
+#define SHELL_NON_SPACE_META_CHARACTERS "|&;()<>[]{}$`'~\"\\*?"
+ if (Sendmail[strcspn(Sendmail, SHELL_NON_SPACE_META_CHARACTERS)] != '\0')
+ {
+mutt_error(_("$sendmail cannot contain shell meta-characters."));
+return -1;
+ }
Also, taking a closer look at the patch.
* strcspn() matches an initial prefix. You might want to use strpbrk()
instead.
* stylistically I don't think you should #define something used just
once right above the usage. If the "why these chars" is unclear, just
add a comment above the block, but I think in this case the mutt_error()
string makes it clear what the check is about.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] Add error when $sendmail has shell metachars
Thanks for the patch, raf. While it *probably* wouldn't cause any harm, I don't think the benefit outweighs the potential risk for committing this to stable. (Also, I generally don't commit new translation strings to stable.) As I mentioned, development is in maintenance mode, so I'm not committing patches to master at this point. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Turning off 'Sender' header for mailing list
Hi Everyone, Recently Gmail has started bouncing emails with any DKIM failures. One source of these failures is the: 'Sender: Mutt-dev ' header added by the mailing list. I realize some of you may be filtering based on that header, but I'm seeing a large number of bounce-unsubscribes due to this, and don't really have a choice. Please filter based off the 'List-Id:' if possible. Sorry for the inconvenience. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Feature request #293
On Sun, Apr 10, 2022 at 10:29:22AM +0100, ckeader wrote: I've completely unified my mutt config for several accounts and while it works very well, I cannot easily tell which account I'm connected to at the moment, and might not remember (yet) which macro switches to which account. The imap accounts generally just show "=INBOX" in the index status line. So I looked at the manual entry for status_format and found that there isn't any shortcut that can help identify the current account. Which is a bit surprising. You could try something like: folder-hook . 'set status_format="-%r-Mutt: [$folder] %f [Msgs:%?M?%M/?%m%?n? New:%n?%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?b? Inc:%b?%?B? Back:%B?%?l? %l?]---(%s/%?T?%T/?%S)-%>-(%P)---" This technique also allows using your own labels instead of $folder: folder-hook .'set my_account="default"' folder-hook 'imap.gmail.com' 'set my_account="gmail"' folder-hook 'imap.yahoo.com' 'set my_account="yahoo"' folder-hook . 'set status_format="-%r-Mutt: [$my_account] %f [Msgs:%?M?%M/?%m%?n? New:%n?%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?b? Inc:%b?%?B? Back:%B?%?l? %l?]---(%s/%?T?%T/?%S)-%>-(%P)---"' -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Make optional for query_command
On Sat, Mar 05, 2022 at 01:20:08AM +0100, Magnus Groß wrote:
To fix this, we replace strtok() with strsep() which is almost
identical, except that it does not skip over consecutive tokens,
therefore the above usecase scenario will work as expected, i.e. will be an empty string and will be the correct
token.
Thank you for the patch. I agree that this is a misbehavior.
I'd almost be willing to include it in the stable branch, except the
query feature is very old, and my experience has taught me that by this
point someone, somewhere, will rely on the strtok() behavior. :-/
However I do think this should be fixed in master at least, with a note
in the UPDATING file describing the change in behavior.
The only problem I see with the patch is that buf is allocated and
reallocated by mutt_read_line(), so using strsep() will introduce a
memory leak - and if a line has too many tabs, possibly a crash when
FREE() is called or safe_realloc() is called in mutt_read_line().
A slightly more intrusive patch using strchr() might be better
(untested, just below). This also removes '\n' from the delim list,
since that's a remnant from when fgets() was used.
diff --git a/query.c b/query.c
index 5a5c07b0..d0617c23 100644
--- a/query.c
+++ b/query.c
@@ -106,7 +106,7 @@ static QUERY *run_query (char *s, int quiet)
int dummy = 0;
char *msg = NULL;
size_t msglen;
- char *p;
+ char *tok, *nexttok;
pid_t thepid;
cmd = mutt_buffer_pool_get ();
@@ -128,27 +128,35 @@ static QUERY *run_query (char *s, int quiet)
msg = mutt_read_line (msg, , fp, , 0);
while ((buf = mutt_read_line (buf, , fp, , 0)) != NULL)
{
-if ((p = strtok(buf, "\t\n")))
+tok = buf;
+if ((nexttok = strchr (tok, '\t')))
+ *nexttok++ = 0;
+
+if (first == NULL)
{
- if (first == NULL)
- {
- first = (QUERY *) safe_calloc (1, sizeof (QUERY));
- cur = first;
- }
- else
- {
- cur->next = (QUERY *) safe_calloc (1, sizeof (QUERY));
- cur = cur->next;
- }
+ first = (QUERY *) safe_calloc (1, sizeof (QUERY));
+ cur = first;
+}
+else
+{
+ cur->next = (QUERY *) safe_calloc (1, sizeof (QUERY));
+ cur = cur->next;
+}
+
+cur->addr = rfc822_parse_adrlist (cur->addr, tok);
+if (nexttok)
+{
+ tok = nexttok;
+ if ((nexttok = strchr (tok, '\t')))
+*nexttok++ = 0;
+ cur->name = safe_strdup (tok);
- cur->addr = rfc822_parse_adrlist (cur->addr, p);
- p = strtok(NULL, "\t\n");
- if (p)
+ if (nexttok)
{
- cur->name = safe_strdup (p);
- p = strtok(NULL, "\t\n");
- if (p)
- cur->other = safe_strdup (p);
+tok = nexttok;
+if ((nexttok = strchr (tok, '\t')))
+ *nexttok++ = 0;
+ cur->other = safe_strdup (tok);
}
}
}
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Moving towards an eventual 2.3.0
As you've probably noticed, I've started making 2.2.x releases off the stable branch. There is also already a commit for 2.2.2, but that release will probably not be until some time in March. My intention going forward is to not commit anything to master except for bug fixes merged from stable. At least, not without review by someone (or someones) that want to head up a 2.3.0 release in the future. So, I'm moving away from leadership, and my time is definitely more limited, but I'm not *gone*. That means this is still an excellent time to get involved. I'm quite willing, nay... eager, to give out commit privileges to people who would like to get more involved. (And, of course, given that I know who you are - random applicants from h@ck3r groups or forks please don't bother). So if you've just been shy to ask, please reconsider. Perhaps as a place to start, several of you could work together as a kind of "maintainer committee". I would even advise very modest goals for 2.3.0. Right now, I'm still available to help with code reviews, try to answer questions, walk through release processes, and help with permission/ownership issues. (One of the places I would start, is trying to get in touch with Michael Elkins again, and make sure he will renew the mutt.org domain in October. We had a scare a couple years ago about that.) After that, I would suggest taking a look at some of the recent bug reports or merge requests on gitlab: - !155 adds support for IMAP ID extension - it seems at least one IMAP server in China requires that. - !156 is some kind of CI change from R2DevOps. If any of you are familiar with that kind of stuff it would be great to see if their proposal is worth it or not. - !162 adds an XDG desktop file for mailto: link support. It also suggests perhaps disabling batch mode when a mailto link is passed. That might be a good idea. - #389 requests ~C to scan Bcc headers too (presumably for searching the "sent" folder). It might also be worth adding to other patterns such as ~L. - #386 seems like a reasonable request. Mutt in classic PGP mode delegates line ending normalization to gpg via the --textmode argument. It requests Mutt to do the work itself to make porting to other backends easier. Thank you, -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: stable vs. master branches
On Tue, Feb 22, 2022 at 04:27:25PM -0800, Kevin J. McCarthy wrote: On Tue, Feb 22, 2022 at 07:07:42PM -0500, Aaron Schrab wrote: 955d281f6 (Add missing period in a comment., 2021-04-08) [...] That was a merge request from someone on gitlab. It fixes a typo in a code comment, so (IMO) doesn't need to go into a stable release. Sorry I missed the point of confusion here. The "AuthorDate:" for the commit is 2021-04-08. I presume it sat in their own branch for the last year and they put it into a merge request after the 2.2.0 release. However the "CommitDate:" is 2022-02-13. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: stable vs. master branches
On Tue, Feb 22, 2022 at 07:07:42PM -0500, Aaron Schrab wrote: Just now after updating my build (based on master) after the release of 2.2.1, I decided to look at the commits that aren't included in the stable branch. Other than the merges of stable back into master I see only one commit: 955d281f6 (Add missing period in a comment., 2021-04-08) Doing a diff between the branches verifies that that's currently the only difference. Was there some reason for not including that in stable? That was a merge request from someone on gitlab. It fixes a typo in a code comment, so (IMO) doesn't need to go into a stable release. If not this seems like a good time to merge the master branch into stable to reduce (temporarily eliminate) the number of commits on master but not in stable. The stable branch is used to create the point releases. e.g. 2.2.1, 2.2.2, 2.2.3... After making any commits to stable, I merge back into master right away so that mainline development contains those bug fixes. Master is used for development towards the next major release, which in this case would be 2.3.0. Master only gets merged into stable right after a major release. For example, I did so just after the 2.2.0 release. The merge should not be done in other cases, because that would pollute the stable branch with potentially "in progress" development. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Unexplained mutt error
On Sun, Feb 20, 2022 at 10:33:41AM -0800, Kevin J. McCarthy wrote: Please don't reply to me personally, it's poor etiquette. Redirecting back to the mailing list. Darn it, that's the second time I've redirected here instead of mutt-users. :-( Please ignore, I'll send again to mutt-users. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Unexplained mutt error
Please don't reply to me personally, it's poor etiquette. Redirecting back to the mailing list. On Sun, Feb 20, 2022 at 11:55:06AM -0600, Ion wrote: Thanks for the speedy reply. There was no prompt. So I added "set confirmcreate = yes" to my .muttrc file and tried gain. No change. Another observation. Mutt shows my IMAP inbox. It seems the problem lies with the SMTP request. I'm not sure why you aren't seeing a "Create xxx?" prompt first. Still, I hypothesize this is from your 'set record ="+Sent"' setting. Are you sure you have a "Sent" folder on your mail.messagingengine.com account, that you can access and write to? On Fastmail, for instance, the correct setting is: set record = "+Sent Items" but perhaps their 'pobox' users are configured differently. -Kevin signature.asc Description: PGP signature
Re: Starting freeze for 2.2.0 release
On Sat, Jan 29, 2022 at 10:03:33PM +, isdtor wrote: ! contrib/smime.rc now uses the cms utility for SMIME encryption/decryption. Kevin, can you please clarify - what is the cms utility? See <https://gitlab.com/muttmua/mutt/-/commit/f0ff78a5d98ee65f7501fbce3231fbe5c886f623> for the commit. It changed the openssl command parameter from "smime" to "cms" for encryption and decryption. I cannot find it on my system. What does it replace in this context? And, is this relevant for the "set crypt_use_gpgme=yes" use case? No this doesn't affect gpgme. + --with-gsasl allows configuration with the GNU SASL library, as an alternative to Cyrus. Cyrus has been around for a long time and it seems that development has either ceased or is proceeding at a glacial pace. Which is fine by me if the software is feature-complete and mature enough to have slowed the discovery of new bugs to a trickle. Are there any opinions on the list whether switching to gsasl is worthwhile for day-to-day users? It seems there are more than those two implementations out there, too. I did this in response to <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999672>. Since the code is new, I invite you to test it. But there are certainly going to be issues to work through, so don't feel obliged to use it. :-) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Starting freeze for 2.2.0 release
I've just sent the mutt.pot file to the translation team. As I mentioned earlier, I plan on releasing the weekend of 2/11-13th. Until that time, commits should be restricted to bug fixes and documentation updates. Please avoid any translation string updates. If you haven't compiled git master in a while, now would be a good time to give it a try and report any issues. I've committed an initial draft of changes to the UPDATING file: 2.2.0 (unreleased): + $pager_skip_quoted_context determines the number of lines to show before unquoted text when using in the pager. ! Quadoption prompts and a few boolean prompts now have a '?' choice, which will display the associated configuration variable. ! , , and can be bound to separate functions/macros. + $sort_thread_groups can be used to sort top-level thread groups differently than subthreads. ! contrib/smime.rc now uses the cms utility for SMIME encryption/decryption. + $compose_confirm_detach_first helps prevent accidentally deleting your typed message in the compose menu. + The $attach_save_charset_convert quadoption prompts to allow charset conversion of received text-type attachments when saving them to disk. + --with-gsasl allows configuration with the GNU SASL library, as an alternative to Cyrus. ! $reply_regexp is now localizable by translators, to add other non-standard prefixes used in the locale. "aw" was removed from the default value. ! $rfc2047_parameters is enabled by default. This wasn't a big release cycle for user-visible changes. :-/ However, I did work on a fair amount of internal cleanup and fixes. I'll mention a few things touched here, just to be aware of when testing: * GPG key search hints now use the entire email address. * SIGPIPE is now reset to the default handler before exec(). * Handling IMAP URLs with embedded passwords was reworked to retain the password. There were a sprinkle of bugs caused by dropping the password in a few places. * The index sort functions were reworked (as part of the $sort_thread_groups rework). * The color parsing code was touched, with respect to "default" value handling. * The compose To: prompt can now be skipped if $ask_cc or $ask_bcc is set, and one of those prompts is filled in. * A few corner cases of $maildir_trash were fixed, with respect to $delete and some mail-stats issues. * SMTP Cyrus SASL authentication was touched. I changed it to be similar to the new gsasl code, allowing long server authentication lines. * A very basic (i.e. incomplete) :cd completion was added. This reused existing code, and doesn't handle issues that arise with completing a command argument (e.g. quoting), so I don't plan on announcing it. ;-) * MUTT_CMD completion was accidentally turned off 20 years ago, but I reenabled it by adding back the missing memcpy. * pager reflow on $wrap modification was fixed. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Upcoming freeze for 2.2.0 and maintainer update
On Fri, Jan 28, 2022 at 03:48:39PM +0100, Vincent Lefevre wrote: On 2022-01-27 09:12:48 -0800, Kevin J. McCarthy wrote: On Thu, Jan 27, 2022 at 02:38:35PM +0100, Vincent Lefevre wrote: > Don't forget to update the copyright year to 2022 where needed. Oh goodness, I did forget, thank you. I'll get that done today. I think that the corresponding *.po files should also be updated if not done yet. Otherwise, the message will be untranslated (some of these messages already are due to a "fuzzy", possibly for other reasons). Thanks, I've just updated those. BTW, "for details type `mutt -vv'" is not immediate to parse due to the missing comma after "details". But there is also "type `mutt -vv' for details" two lines below. Perhaps only the second one should be kept. Good point, but I'll leave this for now. :-) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Upcoming freeze for 2.2.0 and maintainer update
On Thu, Jan 27, 2022 at 02:38:35PM +0100, Vincent Lefevre wrote: Don't forget to update the copyright year to 2022 where needed. Oh goodness, I did forget, thank you. I'll get that done today. And thank you all for your kind replies in this thread! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Upcoming freeze for 2.2.0 and maintainer update
I think it's about time (perhaps a bit past time) to start on the next release! There are a couple more commits I need to get in this week, so I will start the freeze on Friday 1/28. At that time, I'll email the translators and give them two weeks to work on translation updates. Unless something comes up, I'll plan on releasing 2.2.0 the weekend of February 11-13th. I'd also like to announce that 2.2.x is the last series I plan on supporting. That is, I will maintain 2.2.x with bug fixes and security updates, but don't plan on committing to master towards a 2.3.0 release. It's been a pleasure working on Mutt the past 8 or so years, and trying my best to fix and improve things. This isn't a goodbye, but I do intend to back off the maintainership role after this release. Thank you all for your support, and to the development team for giving me the maintainership opportunity. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Arrow keys not working after sending mail involving pinentry-curses
On Sat, Jan 15, 2022 at 06:33:20AM -0800, Kevin J. McCarthy wrote: I'll give it a test and apply your patch this weekend. Applied. Thank you again. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: $reply_prefix
On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote: I strongly disagree with the addition of $reply_prefix (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is contrary to RFC 5322, and non-standard prefixes are annoying in practice and not necessarily recognized by other users. I've reverted the commit. Thank you to everyone for your comments. I'm sympathetic to the desire to control your own MUA. But Vincent, Eike, Will, and Derek have been involved in Mutt far longer than I have, and I trust their judgment. When all of them agree, it's a strong sign I need to rethink things. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Arrow keys not working after sending mail involving pinentry-curses
On Sat, Jan 15, 2022 at 02:28:20PM +0100, Robert Bartel wrote: As I'm not a curses expert, I could be wrong and ask here if anyone can confirm or reject this reasoning. Maybe there is a better way to fix this issue. Nice debugging! You are correct, the call should definitely be after the sendmail is invoked, for the reasons you mention. I'll give it a test and apply your patch this weekend. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: $reply_prefix
On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote: Kevin J. McCarthy wrote on Thu, 13 Jan 2022 at 23:20:55 EST in : I've been told other prefixes are often used in some lists, and the practice is getting more common. Why not give users the option to adjust it, if they deem it appropriate, for some lists? The reason not to is that the knob encourages the proliferation of alternative prefixes and that is bad for everyone. I think we'll have to disagree about what encouragement is, then. IMHO the option enables, but doesn't encourage. I also think Mutt is generally used by the technically inclined who care about email and netiquette. One is confined to the content of a message and the other affects critical message metadata that is often displayed in abbreviated form. "Critical message metadata" that is (*ahem*) gently suggested via MAY in the RFC. However, I am listening, and if the general consensus is that this option is a bad idea, I will back it out. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: $reply_prefix
On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote: I strongly disagree with the addition of $reply_prefix (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is contrary to RFC 5322, and non-standard prefixes are annoying in practice and not necessarily recognized by other users. Why strongly against? $reply_regexp has had "aw" listed for years (although I just took that out of the default value too...). I've been told other prefixes are often used in some lists, and the practice is getting more common. Why not give users the option to adjust it, if they deem it appropriate, for some lists? I'm willing to back the change out, but Mutt also gives the option for crazy things like $indent_string. I don't think by giving the option I'm *encouraging* it, but it does make it easier to adjust if they want. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Mutt on ubuntu 20
On Tue, Jan 11, 2022 at 03:32:09PM -0600, Derek Martin wrote: OK but do you agree that behavior is wrong? :) It's one header, regardless of the wrapping... I'll have to think more closely about it. I do agree that the matching on the folded line overriding the previous 'color header' match is confusing. I don't believe the fix is hard, either. However, it's not just about wrong vs. right, but also about precedence of the behavior, and I believe this one goes back to 1.5.21. If I make the change, I may then have long-time users reporting a "genuine" regression. But that's not a "no". I'm winding down the 2.2.0 development cycle now, so I'll put this at the top of the list to consider in the next cycle. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Mutt on ubuntu 20
On Tue, Jan 11, 2022 at 12:48:03PM -0600, Derek Martin wrote: On Mon, Jan 10, 2022 at 05:27:32PM -0800, Kevin J. McCarthy wrote: Can you provide a minimal reproduce of the problem? I sure can: set spoolfile = Path/to/coninued/header/message/folder color normal default default color header brightgreen default . color header brightmagenta default ^(subject|from|to|cc|date) With these, the specified headers will all be magenta. That is, unless they are continued--then they will be green. I can reproduce this with versions 1.10.1 and 1.11.4, and so I don't believe this is a regression. When the header wraps, the second color line above will match the wrapped line, and will then override the third color lines' match of the first header line. I think instead you probably want: color normal default default color hdrdefault brightgreen default color header brightmagenta default ^(subject|from|to|cc|date) On a separate note, I tried to compile 2.1.5 with the sidebar enabled, and I got this mess (which I made no effort to investigate, but I can later, theoretically, if you like), just FYI: I can't reproduce this from a fresh unpacked tarball. The first line you should see when you type make is: ./gen_defs ./OPS ./OPS.SIDEBAR ./OPS.PGP ./OPS.SMIME ./OPS.CRYPT > keymap_defs.h Which should generate the OP_SIDEBAR_* declarations in keymap_defs.h. Try a make clean; make and see if that fixes the problem? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Mutt on ubuntu 20
On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote: 2. It appears that this version of Mutt does not properly honor color commands in headers that are continued in multiple lines. Is this a bug that was found and fixed in a future version? (I can obviously download the source and try it but that takes some time I don't really have right at the moment, so if someone knows the answer, all the better). Derek, I can't recall a recent fix pertaining to that, but perhaps I've forgotten. Can you provide a minimal reproduce of the problem? You don't have $header_color_partial set, do you? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Enabling $rfc2047_parameters by default
On Mon, Jan 10, 2022 at 06:08:12PM -0600, Derek Martin wrote: On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote: I'm thinking about enabling $rfc2047_parameters by default, and would like to hear any counter-arguments against this. I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec. I guess it's theoretically possible someone would want an attachment named that way, but it doesn't sound likely. :-/ However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed? If anyone else has a pointer please let me know, but I'll try to take a look. One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it. I think it's because 2231 both provides encoding and allows the parameters to be split across multiple lines and reassembled. The intro to the rfc also discusses the reason language information was added. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Enabling $rfc2047_parameters by default
I'm thinking about enabling $rfc2047_parameters by default, and would like to hear any counter-arguments against this. Here we are in 2022, yet I still occasionally receive tickets, or most recently even a merge request (!154), about this. Obviously some mail clients are *still* improperly applying 2047 encoding. Making the situation worse, the config variable name isn't intuitive (to someone who isn't familiar with the relevant rfcs), so the user usually has no idea how to fix the problem. Even the merge request author, who was skilled enough to hack the code, wasn't aware there was already a variable. To me, enabling the variable has low potential risk and would definitely save user frustration, but I'd like to hear if there are potential downsides to doing this. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: LC_TIME affects mutt's charset value
On Thu, Dec 16, 2021 at 03:15:29PM +0100, Petr Pisar wrote: V Thu, Dec 16, 2021 at 02:21:40PM +0100, Daan van Rossum napsal(a): With the following locale variables set # env | grep -e LANG -e LC_ LANG=en_US.UTF-8 LC_TIME=en_DE.UTF-8 Is en_DE.UTF-8 a valid locale on your system? "local -a" on my glibc system does not recognize it. This does seem to be the problem. Mutt calls nl_langinfo(CODESET), and that is returning "ANSI_X3.4-1968" when LC_TIME is set to the (bogus) value above. Mutt then canonicalizes that return value back to us-ascii. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Fix Unused Variable Warning
On Wed, Nov 24, 2021 at 01:51:32PM -0600, Aaron Poffenberger wrote: Here's a small patch to fix a warning in mutt_ssl.c: Applied. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Use From-address fqdn for Message-ID Generation
On Mon, Nov 22, 2021 at 01:30:30PM -0600, Aaron Poffenberger wrote: I'm happy to try changing configuration using an unpatched version, but I have to be careful sending too many test messages to ATT/sbcglobal.net. They have an itchy RBL trigger. I'd appreciate if you would try it out. Due to the US holiday coming up, I won't be able to take a closer look until next week, so if you have time please do try verifying a failure and then retrying exactly the same thing except for swapping *only* the message-id via 'set message_id_format = "<%z...@example.com>"'. I'm curious what you and the other say changes in the headers under the various conditions of setting hostname or message_id_format. The only changes I'm seeing in the headers when hostname is set is the fqdn of the Message-ID. We're concerned with the SMTP envelope, which won't be reflected in the headers saved in your Sent folder. That is usually the cause for these kinds of errors, because the MTA itself isn't usually digging inside the message itself (except for spam processing). $hostname is used by mutt_fqdn() and mutt_default_from(). The $smtp_url handling uses it for an initial EHLO. Bouncing can also use this. Email addresses without a hostname can also ending up using it. So there are some possibilities it's leaking into the "envelope from" somehow, but I haven't looked deeply at the flow yet. Maybe $use_envelope_from is set in your muttrc, or the envelope from is being set in msmtp some other way dependent on your $hostname. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Use From-address fqdn for Message-ID Generation
On Mon, Nov 22, 2021 at 12:06:29PM -0600, Aaron Poffenberger wrote: On 2021-11-22 09:50 -0800, Kevin J. McCarthy wrote: On Mon, Nov 22, 2021 at 11:22:33AM -0600, Aaron Poffenberger wrote: > I know this is related to Message-ID because if I go into muttrc(5) > and put `set hostname="example.com"` and send again to > u...@sbcglobal.net, the message goes through without issue. Well, setting $hostname can affect other things too. Without the patch, if you *just* change your $message_id_format to "<%z...@example.com>" you are saying it goes through. Are you using $smtp_url or a local MTA? Are there any other possible variables? I use msmtp: set sendmail=/usr/local/bin/msmtp In my case just setting hostname was enough to fix it. Setting message_id_format would probably work as well, but it would also mean all emails sent through other email domains would have Message-IDs from a different domain. In my case I send from 5 different email domains. I understand, but I wasn't asking you to make a permanent change to your configuration; just to try setting the $message_id_format directly as I instructed without touching hostname (or anything else). As I and others in the thread have said, what you are describing makes no sense, so we'd like more cooperation verifying and helping to debug the behavior. The behavior you are describing is highly unusual, as the MTA is usually just looking at the EHLO and envelope addresses. > Also, as noted in my original, setting the fqdn of the Message-ID to > the fqdn of the From address make sense. When I'm sending email from > my laptop through gmail.com, the Message-ID picks-up the fqdn of my > laptop rather than using gmail.com. The purpose of the Message-ID is to be unique. Setting to the RHS to the local machine reduces the scope of randomness needed on the left side. There's no need or sense behind using the from domain. Mail.app uses @. The Google web interface uses @mail.gmail.com. Notifications come from @notifications.gmail.com. Sorry, I misspoke. I meant simply there is no *need* to use the from domain in the RHS. I don't believe Mutt's randomness for the LHS is sufficient to encompass a large domain by default, so would still be opposed to this. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Use From-address fqdn for Message-ID Generation
On Mon, Nov 22, 2021 at 10:09:16AM -0600, Aaron Poffenberger wrote:
Lastly, the patch updates the documentation and changes the default
message_id_format from "<%z@%f>", to "<%z@%F>" so that Message-IDs are
always generated using the fqdn of the From address.
I'm against changing the default. The behavior you're describing by
AT is insane, and I don't believe Mutt's LHS randomization is strong
enough to support the from address domain by default.
diff --git a/messageid.c b/messageid.c
index e4ac4410..2ab63288 100644
--- a/messageid.c
+++ b/messageid.c
@@ -30,6 +30,7 @@ typedef struct msg_id_data
time_t now;
struct tm tm;
const char *fqdn;
+ const char *from_fqdn;
} MSG_ID_DATA;
-char *mutt_gen_msgid (void)
+char *mutt_gen_msgid (const char *from)
{
MSG_ID_DATA id_data;
BUFFER *buf, *tmp;
@@ -124,9 +129,17 @@ char *mutt_gen_msgid (void)
if (!(id_data.fqdn = mutt_fqdn(0)))
id_data.fqdn = NONULL(Hostname);
+ /* from should be a fully-formatted email address,
+ * nevertheless, handle cases where the caller
+ * sends just the fqdn or NULL. */
+ if (!from)
+id_data.from_fqdn = id_data.fqdn;
+ else if (!(id_data.from_fqdn = strchr (from, '@') + 1))
If there is no '@' in from, it looks like id_data.from_fqdn would have
value (NULL + 1).
+id_data.from_fqdn = from;
+
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: Use From-address fqdn for Message-ID Generation
On Mon, Nov 22, 2021 at 11:22:33AM -0600, Aaron Poffenberger wrote: I know this is related to Message-ID because if I go into muttrc(5) and put `set hostname="example.com"` and send again to u...@sbcglobal.net, the message goes through without issue. Well, setting $hostname can affect other things too. Without the patch, if you *just* change your $message_id_format to "<%z...@example.com>" you are saying it goes through. Are you using $smtp_url or a local MTA? Are there any other possible variables? The behavior you are describing is highly unusual, as the MTA is usually just looking at the EHLO and envelope addresses. Also, as noted in my original, setting the fqdn of the Message-ID to the fqdn of the From address make sense. When I'm sending email from my laptop through gmail.com, the Message-ID picks-up the fqdn of my laptop rather than using gmail.com. The purpose of the Message-ID is to be unique. Setting to the RHS to the local machine reduces the scope of randomness needed on the left side. There's no need or sense behind using the from domain. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Option to clear the screen on quit
On Fri, Oct 22, 2021 at 12:51:04PM +0200, Vincent Lefevre wrote: Following my remark about the privacy reason, I think that the patch would be useful to make sure that data are not silently left on the alternate screen (which is no longer visible after quitting Mutt, but can be retrieved at least in xterm with its menus, and possibly via escape sequences I think). I don't feel _strongly_ against the patch, but absent a real threat model I'm still not convinced it belongs inside Mutt. After 25 years of this behavior, is clearing the alternate screen really now a security or privacy issue; against an attacker who evidently has access to your terminal? A quick test showed vim and less also leave the alternate state as-is. However, I'm often wrong, and so invite others to please tell me I'm being an idiot (again). :-) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: ctime, POSIX and ISO C
On Fri, Oct 22, 2021 at 12:41:39PM +0200, Vincent Lefevre wrote: ctime() may be marked obsolescent in the POSIX guide, but it is still specified by ISO C, and AFAIK, not marked obsolescent there, even in the latest C2x draft N2176. I guess POSIX and ISO C should get together and talk then. I had this one on my todo list for a few years now, after noticing in the man page: POSIX.1-2008 marks asctime(), asctime_r(), ctime(), and ctime_r() as obsolete, recommending the use of strftime(3) instead. Moreover, ISO C says: "It is equivalent to asctime(localtime(timer))" So, if you want to replace ctime(), why no using just that? asctime() is obsolete too. I don't insist on this commit if we're confident it won't be removed. However the latest POSIX still has them marked as such. Since it's an easy (and critical to Mutt) function, it seemed prudent to just roll our own. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Option to clear the screen on quit
On Sun, Oct 17, 2021 at 12:25:24AM -0500, Oskari Pirhonen wrote: Add the option to clear the screen when quitting mutt. This is controlled by the clear_on_quit config option. Defaults to "no". I think most terminals nowadays have alternative screen support enabled by default, don't they? Unless this is a common option in other applications, I don't feel like this belongs inside Mutt. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Crashes in recent builds from master
On Wed, Sep 08, 2021 at 09:09:03AM -0700, Kevin J. McCarthy wrote: On Wed, Sep 08, 2021 at 03:56:56AM -0700, Kevin J. McCarthy wrote: However, I haven't been able to figure out the memory error leading to a crash yet. It would be helpful if you could run with ASAN enabled until you get the crash(es). With ASAN you'll need to arrange it so the tmux window doesn't close when mutt crashes so you can read the ASAN report. To trigger the QRESYNC failure, delete some messages in the mailbox using mutt. Sync and exit the mailbox, wait till there are more new messages in that mailbox and reopen using mutt. I was able to trigger the crash, and I've figured out the problem. I'll push a commit to a branch for testing later on today. I've pushed several commits to branch 'kevin/stable-fixes'. As the branch says, it's based on 'stable' and so doesn't have the thread changes in master. However, I've also pushed up a branch 'kevin/master-stable-fixes-rebase-test' that has those commits merged in to master. I need to clean things up and test more, but would appreciate if you would test it too. Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Crashes in recent builds from master
On Wed, Sep 08, 2021 at 03:56:56AM -0700, Kevin J. McCarthy wrote: However, I haven't been able to figure out the memory error leading to a crash yet. It would be helpful if you could run with ASAN enabled until you get the crash(es). With ASAN you'll need to arrange it so the tmux window doesn't close when mutt crashes so you can read the ASAN report. To trigger the QRESYNC failure, delete some messages in the mailbox using mutt. Sync and exit the mailbox, wait till there are more new messages in that mailbox and reopen using mutt. I was able to trigger the crash, and I've figured out the problem. I'll push a commit to a branch for testing later on today. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Crashes in recent builds from master
On Tue, Sep 07, 2021 at 09:50:05PM -0700, Kevin J. McCarthy wrote: On Tue, Sep 07, 2021 at 11:45:03PM -0400, Aaron Schrab wrote: At 18:00 -0700 07 Sep 2021, "Kevin J. McCarthy" wrote: Are you using $imap_qresync or $imap_condstore? Yes, I have both of those enabled (using dovecot 2.3.16 from Debian unstable as the IMAP server). In at least some of the crashes I believe I've seen messages about QRESYNC failing immediately before; but I generally have mutt running in a tmux window that's set to close when mutt exits so the message is generally only visible very briefly. That gives me some ideas. I'll take a closer look, but I think my fix in commit 74ce032f may have caused some other issues with $imap_qresync. Yes, it looks like commit 74ce032f was incorrect. I'll need to fix that and make another stable release soon. However, I haven't been able to figure out the memory error leading to a crash yet. It would be helpful if you could run with ASAN enabled until you get the crash(es). With ASAN you'll need to arrange it so the tmux window doesn't close when mutt crashes so you can read the ASAN report. To trigger the QRESYNC failure, delete some messages in the mailbox using mutt. Sync and exit the mailbox, wait till there are more new messages in that mailbox and reopen using mutt. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Crashes in recent builds from master
On Tue, Sep 07, 2021 at 11:45:03PM -0400, Aaron Schrab wrote: At 18:00 -0700 07 Sep 2021, "Kevin J. McCarthy" wrote: Are you using $imap_qresync or $imap_condstore? Yes, I have both of those enabled (using dovecot 2.3.16 from Debian unstable as the IMAP server). In at least some of the crashes I believe I've seen messages about QRESYNC failing immediately before; but I generally have mutt running in a tmux window that's set to close when mutt exits so the message is generally only visible very briefly. That gives me some ideas. I'll take a closer look, but I think my fix in commit 74ce032f may have caused some other issues with $imap_qresync. I don't see how it's causing the crash, but it may be that I didn't properly reset something if verifying the qresync failed, leading to a stray pointer. I'll try to take a closer look the next couple days. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Crashes in recent builds from master
On Tue, Sep 07, 2021 at 07:15:16PM -0400, Aaron Schrab wrote: Since updating from a build based on bcdb61560 (Add %T status format for $sort_thread_groups., 2021-08-05) to one based on 27e61da56 (Merge branch 'stable', 2021-08-24) I've been experiencing some sporadic crashes. Unfortunately both IMAP and thread code *have* been touched recently. So it looks like I goofed something up. :-( However, bcdb61560 isn't on master. Were you running off of my development branch before, or were you perhaps referring to 5aa75ed2? You may also want to try enabling ASAN via something like export CFLAGS='-g3 -fno-omit-frame-pointer -fsanitize=address' and re-configure/recompile, to see if it can give an earlier warning about memory corruption. For the more troublesome one I get the following backtrace. Once this comes up it will keep crashing when I attempt to change to the same folder, at least in the short term. Although if I open this folder once with the old build then switch back to the new build the problem will go away for awhile. Are you using $imap_qresync or $imap_condstore? The stack is in a pretty benign section, so it seems like it's a wild pointer or something corrupting memory. The other problem seems to occur on line 431 of thread.c: →· !tmp->fake_thread &&→·→· /* don't match pseudo threads */ I usually test with $strict_threads enabled. I'll turn that off and see if I can trigger the problem. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Use cms utility for SMIME encryption/decryption.
On Wed, Aug 25, 2021 at 04:00:31PM -0400, Craig Gallek wrote: The openssl smime utility only supports RSA keys for encryption (more specifically, the PKCS7 container that it uses can't be used with other key types). The cms utility supports newer versions of the SMIME RFCs, including the use DH ephemeral-static algorithms for encrypting the symmetric key used during message encryption. Thanks for the patch. I haven't used S/MIME in a while, but if Debian has already made the change this seems safe enough. I've applied and pushed it up to master. If anyone encounters issues with the change please let me know. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] bugfix for handling incomplete IMAP header cache
On Mon, Aug 23, 2021 at 10:48:59AM +0200, Oswald Buddenhagen wrote: On Sun, Aug 22, 2021 at 06:35:46AM -0700, Kevin J. McCarthy wrote: I agree the server wasn't behaving nicely. It simply omitted some of the headers. (Probably they were deleted at some point between the "assembly" of the mailbox on its side and sending all the headers - the mailbox was very large and changing constantly I think.) However the MSNs didn't repeat or exceed the initial max MSN reported, so I think it might be debatable if it was broken. unless the problem was misdiagnosed due to mutt's tracking of unsolicited EXPUNGE and EXISTS responses being actually broken, No, I remember going through the log. It was during the initial connect header FETCH. There were gaps in the result sequence numbers, e.g. 1, 2, 3, 5, 6, 8, 9, There weren't any EXPUNGE responses (which would have been illegal during the FETCH processing in any case.) that server would be most definitely broken. there is absolutely no wiggle room here. Okay, that's clear enough, and I believe you. :-) So, Pieter-Tjerk, perhaps I'm being too strict about the index assignment then. Again, I don't want to make that change for stable, (and in any case I think we should be sorting by UID to prevent any other possible issues like this in the future). But let me take a second look for master. My concern is violating that general assumption that index is in the range of 0..msgcount-1. The other mail backends make use of that, but that's independent of the IMAP code of course. I looked at the Index Menu usage a while ago, and I think I came to the conclusion it might be safe, but there was some ambiguous usage in there. I will take a second look at that. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] bugfix for handling incomplete IMAP header cache
On Sun, Aug 22, 2021 at 12:55:49PM +0200, Pieter-Tjerk de Boer via Mutt-dev wrote: On Sat, Aug 21, 2021 at 12:50:20PM -0700, Kevin J. McCarthy wrote: This was observed in Trac ticket 3942: <https://gitlab.com/muttmua/trac-tickets/-/blob/master/tickets/closed/3942-mutt_with_hanging_on_large_Exchange_Deleted_Messages_folder.txt> Ouch, that seems a rather severely broken IMAP server implementation then. The assumption, made by mutt and discussed in that ticket, namely that the MSNs are consecutive and can't exceed the message count, is in fact well supported by the RFC: not just by the sentence I quoted but also by the further examples given in that RFC. I agree the server wasn't behaving nicely. It simply omitted some of the headers. (Probably they were deleted at some point between the "assembly" of the mailbox on its side and sending all the headers - the mailbox was very large and changing constantly I think.) However the MSNs didn't repeat or exceed the initial max MSN reported, so I think it might be debatable if it was broken. Well, as a user, I would expect 'unsorted' to match the order the messages have on the IMAP server. This is practically useful, as it ensures that the latest additions to the mailbox are all together at the end. Could we solve this by applying my previous patch, and adding a check at the end that the index values (derived from MSN as per my patch) are in fact consecutive, and modifying them as needed? I wouldn't be willing to do this for these stable branch fixes. I'd have to think about it for master. My inclination is to leave the index separate from MSN. The mis-order is not an ordinary situation, so I don't think it's worth reintroducing the complication for this case. On Sat, Aug 21, 2021 at 01:21:37PM -0700, Kevin J. McCarthy wrote: I've pushed up two commits to branch kevin/stable-imap-header-cache-hole on gitlab. <https://gitlab.com/muttmua/mutt/-/commits/kevin/stable-imap-header-cache-hole>. The first is your msn_begin fix commit and the second is a currently untested commit changing the sort order before generating msgset strings. Nice! For what it's worth, I tested it the same way as I tested my own earlier patch (triggering the bug by temporarily making the IMAP server unreachable), and it works okay in that case. Thank you for testing the fixes. I'm going to test and look at it some more the next few days, but will get a stable release out with these fixes this week. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] bugfix for handling incomplete IMAP header cache
On Sat, Aug 21, 2021 at 07:15:12AM -0700, Kevin J. McCarthy wrote: Thank you - good catch. I'll apply this as a separate patch today. I've pushed up two commits to branch kevin/stable-imap-header-cache-hole on gitlab. <https://gitlab.com/muttmua/mutt/-/commits/kevin/stable-imap-header-cache-hole>. The first is your msn_begin fix commit and the second is a currently untested commit changing the sort order before generating msgset strings. I'm going to stare at it a while, and test it the rest of this weekend. If you have the time inclination please feel free to give it try too. Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: gnutls Cipher-Settings/Syntax
On Fri, Aug 20, 2021 at 10:30:22AM -0700, Kevin J. McCarthy wrote: [Please reply to the mailing list, not directly to me. Redirecting back to the mailing list] Sorry, I "manually" fixed it to the wrong list. :-) I've sent the response again to mutt-users. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: gnutls Cipher-Settings/Syntax
[Please reply to the mailing list, not directly to me. Redirecting back to the mailing list] On Fri, Aug 20, 2021 at 07:16:56PM +0200, Stefan Rohnke wrote: Am Fri, Aug 20, 2021 at 09:08:23AM -0700 schrieb Kevin J. McCarthy: What is the URL you have Mutt configured to connect to? https://imap.arcor.de:465 is the url. Port 465 is the smtps submission port. I can't get a response from that port myself. When I change ssl_cipers to: ssl_ciphers="NORMAL:+VERS-TLS1.2" Or every other Parameters i get the following Message: [2021-08-20 19:13:13] gnutls_priority_set_direct(NORMAL:+VERS.TLS1.2:-VERS-TLS1.2:-VERS-TLS1.1:-VERS-TLS1.0): Die Anfrage ist ungültig. "-VERS-TLS1.2" is appended to the string if $ssl_use_tlsv1_2 is unset. However, by default, that variable is set. You should check your muttrc to see if you have unset it somewhere. -Kevin signature.asc Description: PGP signature
Re: [PATCH] Prompt for password when using encrypted client certificate
On Mon, Aug 16, 2021 at 09:01:31AM -0400, Craig Gallek wrote: Thanks for the review. The gnutls change has been merged. I've tested the ssl_client_cert option with an encrypted key when built against both openssl and gnutls. Both prompt for a decryption password now before successfully connecting. Please let me know if there in any other testing you would like to see. I've applied and pushed it up. Thanks again for the patch. Your confirmation it works is good enough for me (plus the similarity to the OpenSSL code). However, if anyone else out there is using encrypted client-certs, and has the capacity to test against GnuTLS git master, please do give it a try. :-) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Prompt for password when using encrypted client certificate
On Wed, Aug 11, 2021 at 03:02:30PM -0400, Craig Gallek wrote: This already worked when compiled against openssl, but not with gnutls. Looks like this is based on the OpenSSL calls. If you can verify it works for you, I have no problem with the patch. I figured it would be good to get some early feedback on this, though. In particular, do you care that this duplicates a translation string? It could certainly be put in a common place, but I wasn't sure where. It's not a problem to duplicate translation strings, so this is fine. This change is safe with or without the gnutls change. It simply won't call the prompt callback with older versions of gnutls (though, it's proabably best to wait for that change anyway to ensure that this callback mechanism will be the one actually used). I agree. Let's wait until your merge request is accepted. If you wouldn't mind sending a followup email then, I'll be glad to merge it at that point. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: strfcpy in dotlock.c
On Thu, Jul 22, 2021 at 09:11:56AM -0700, Kevin J. McCarthy wrote: What do you think of using memccpy in the strfcpy macro, if it's available, as Ian suggested? I've pushed a commit up to branch `kevin/warnings` doing this. memccpy() returns a different value than strncpy(), but it doesn't appear Mutt is making use of the strfcpy return value anywhere. I also reverted the dotlock commit in that branch. If anyone has any comments against this, please let me know. Otherwise I'll merge it into master this weekend. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: strfcpy in dotlock.c
On Thu, Jul 22, 2021 at 12:11:17PM +0200, Vincent Lefevre wrote: Silence strfcpy() warning in dotlock_deference_symlink(). Yeah, I thought about this commit for a while, because I wasn't joyful about making the change just to silence the compiler in this case. The other warning-fix commits I made, prior to this commit, were at least not-nonsensical, but this last one did not make me happy. The strfcpy definition seems wrong: # define strfcpy(A,B,C) strncpy (A,B,C), *(A+(C)-1)=0 Funnily enough I noticed this too, before I started fixing the warnings. But when I made this change it produced even more warnings. I think because of the logic Ian described in his reply. I would say that it is better to silence the warning with -Wno-stringop-truncation rather than trying to avoid it in the code. I was sorely tempted. However, I'll note that this warning DID produce some bug fixes I made in the stable branch. What do you think of using memccpy in the strfcpy macro, if it's available, as Ian suggested? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Add skip_quoted_context option
On Mon, Jun 14, 2021 at 07:44:24PM -0700, Kevin J. McCarthy wrote:
I still need to test more when I have time tomorrow, so please let me
know if there are problems with this version.
And... right after I hit send, I noticed I forgot to include the
(drretval < 0) test after the initial scan. I've copied that up and am
attaching the modified patch.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
From f06d18360b610366ce68d8ebf9d6a39a0572ec01 Mon Sep 17 00:00:00 2001
From: Rene Kita
Date: Sun, 13 Jun 2021 15:56:58 +0200
Subject: [PATCH] Add skip_quoted_context option.
Using skip-quoted the first unquoted line becomes the new top line
displayed in the pager. This leaves the user with no context to know
what the answer refers to.
Add an option to keep some lines of context when using skip-quoted.
With skip_quoted_context set to 5, skip-quoted will show at most 5 lines
of the previous quote. If the previous quote is shorter than 5 lines the
whole quote will be displayed.
This option defaults to 0 to remain backwards compatible.
---
globals.h | 1 +
init.h| 9 +++
pager.c | 76 +++
3 files changed, 64 insertions(+), 22 deletions(-)
diff --git a/globals.h b/globals.h
index 859732e6..06ce410e 100644
--- a/globals.h
+++ b/globals.h
@@ -234,6 +234,7 @@ WHERE short HistSize;
WHERE short MenuContext;
WHERE short PagerContext;
WHERE short PagerIndexLines;
+WHERE short PagerSkipQuotedContext;
WHERE short ReadInc;
WHERE short ReflowWrap;
WHERE short SaveHist;
diff --git a/init.h b/init.h
index acc7d8b2..26784882 100644
--- a/init.h
+++ b/init.h
@@ -2386,6 +2386,15 @@ struct option_t MuttVars[] = {
** is less than $$pager_index_lines, then the index will only use as
** many lines as it needs.
*/
+ { "pager_skip_quoted_context", DT_NUM, R_NONE, {.p=}, {.l=0} },
+ /*
+ ** .pp
+ ** Determines the number of lines of context to show before the
+ ** unquoted text when using \fC$\fP. When set to a
+ ** positive number at most that many lines of the previous quote are
+ ** displayed. If the previous quote is shorter the whole quote is
+ ** displayed.
+ */
{ "pager_stop", DT_BOOL, R_NONE, {.l=OPTPAGERSTOP}, {.l=0} },
/*
** .pp
diff --git a/pager.c b/pager.c
index 700af2d6..bb5d495b 100644
--- a/pager.c
+++ b/pager.c
@@ -2573,33 +2573,65 @@ search_next:
{
int dretval = 0;
int new_topline = rd.topline;
+ int num_quoted = 0;
- while ((new_topline < rd.lastLine ||
- (0 == (dretval = display_line (rd.fp, _pos, ,
- new_topline, , , MUTT_TYPES | (flags & MUTT_PAGER_NOWRAP),
- , _level, _redraw, , rd.pager_window
- && rd.lineInfo[new_topline].type != MT_COLOR_QUOTED)
- new_topline++;
+ if (PagerSkipQuotedContext < 0)
+PagerSkipQuotedContext = 0;
- if (dretval < 0)
- {
- mutt_error _("No more quoted text.");
- break;
- }
+ /* Skip past previous "context" quoted lines */
+ if (PagerSkipQuotedContext > 0)
+ {
+ while ((new_topline < rd.lastLine ||
+ (0 == (dretval = display_line (rd.fp, _pos, ,
+ new_topline, , , MUTT_TYPES | (flags & MUTT_PAGER_NOWRAP),
+ , _level, _redraw, , rd.pager_window
+ && rd.lineInfo[new_topline].type == MT_COLOR_QUOTED)
+ {
+ new_topline++;
+ num_quoted++;
+ }
- while ((new_topline < rd.lastLine ||
- (0 == (dretval = display_line (rd.fp, _pos, ,
- new_topline, , , MUTT_TYPES | (flags & MUTT_PAGER_NOWRAP),
- , _level, _redraw, , rd.pager_window
- && rd.lineInfo[new_topline].type == MT_COLOR_QUOTED)
- new_topline++;
+ if (dretval < 0)
+ {
+ mutt_error _("No more unquoted text after quoted text.");
+ break;
+ }
+ }
- if (dretval < 0)
- {
- mutt_error _("No more unquoted text after quoted text.");
- break;
+ if (num_quoted <= PagerSkipQuotedContext)
+ {
+ num_quoted = 0;
+ while ((new_topline < rd.lastLine ||
+ (0 == (dretval = display_line (rd.fp, _pos, ,
+ new_topline, , , MUTT_TYPES | (flags & MUTT_PAGER_NOWRAP),
+ , _level, _redraw, , rd.pager_window
+ && rd.lineInfo[new_topline].type != MT_COLOR_QUOTED)
+ new_topline++;
+
+ if (dretval < 0)
+ {
+ mutt_error _("No more quoted text.");
+ break;
+ }
+
+ while ((new_topline < rd.lastLine ||
+ (0 == (dretval = display_line (rd.fp, _pos, ,
+ new_topline, , , MUTT_TYPES | (flags & MUTT_PAGER_NOWRAP),
+ , _level, _redraw, , rd.pager_window
+ && rd.lineInfo[new_topline].type == MT_COLOR_QUOTED)
+ {
+ new_topline++;
+ num_quoted++;
+ }
+
+ if (dretval <
Re: [PATCH] Add skip_quoted_context option
On Mon, Jun 14, 2021 at 05:49:50AM -0700, Kevin J. McCarthy wrote:
I'll take a closer look at the patch in the next couple days.
While looking it over again, I noticed the patch had a few more
issues.
The outer while loop shouldn't be really needed, because we shouldn't be
looping repeatedly over those inner scans.
Its test 'SkipQuotedContext > 0' disabled when the context
was 0 (as I noted before).
Also the test 'new_topline <= rd.topline + SkipQuotedContext' didn't
quite make sense, because a large SkipQuotedContext could cause the
function to skip one or more initial quotes and responses, if they were
short.
I'm attaching a modified version of your patch that:
- renames the variable to $pager_skip_quoted_context.
- adds an initial scan for quoted lines if $pager_skip_quoted_context is
greater than 0. If it finds more than $pager_skip_quoted_context
initial quote lines it just recomputes context and redisplays.
Otherwise it continues with the original scan, and
recomputes context at the end of that.
- since num_quoted will be less than new_topline, removes the context
variable and just subtracts MIN(PagerSkipQuotedContext, num_quoted).
- removes the commit comment about wrapped lines (they do in fact count,
because display_line() is computing a single output line, not input
line).
As with your patch, the change looks bigger than it is because of the
indent changes. It's easier to see the change when diff ignores
whitespace. I've pasted that version for pager.c below.
Since this is your idea and your work, I've purposely left you as Author
in the commit.
I still need to test more when I have time tomorrow, so please let me
know if there are problems with this version.
Thank you!
modified pager.c
@@ -2573,7 +2573,28 @@ search_next:
{
int dretval = 0;
int new_topline = rd.topline;
+ int num_quoted = 0;
+ if (PagerSkipQuotedContext < 0)
+PagerSkipQuotedContext = 0;
+
+ /* Skip past previous "context" quoted lines */
+ if (PagerSkipQuotedContext > 0)
+ {
+ while ((new_topline < rd.lastLine ||
+ (0 == (dretval = display_line (rd.fp, _pos,
,
+ new_topline, , , MUTT_TYPES |
(flags & MUTT_PAGER_NOWRAP),
+ , _level, _redraw,
, rd.pager_window
+ && rd.lineInfo[new_topline].type == MT_COLOR_QUOTED)
+ {
+ new_topline++;
+ num_quoted++;
+ }
+ }
+
+ if (num_quoted <= PagerSkipQuotedContext)
+ {
+ num_quoted = 0;
while ((new_topline < rd.lastLine ||
(0 == (dretval = display_line (rd.fp, _pos,
,
new_topline, , , MUTT_TYPES |
(flags & MUTT_PAGER_NOWRAP),
@@ -2592,14 +2613,19 @@ search_next:
new_topline, , , MUTT_TYPES |
(flags & MUTT_PAGER_NOWRAP),
, _level, _redraw,
, rd.pager_window
&& rd.lineInfo[new_topline].type == MT_COLOR_QUOTED)
+ {
new_topline++;
+ num_quoted++;
+ }
if (dretval < 0)
{
mutt_error _("No more unquoted text after quoted text.");
break;
}
- rd.topline = new_topline;
+ }
+
+ rd.topline = new_topline - MIN (PagerSkipQuotedContext, num_quoted);
}
break;
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
From 4d382f133dc5196bf9972be6768069e40aa4b9e8 Mon Sep 17 00:00:00 2001
From: Rene Kita
Date: Sun, 13 Jun 2021 15:56:58 +0200
Subject: [PATCH] Add skip_quoted_context option.
Using skip-quoted the first unquoted line becomes the new top line
displayed in the pager. This leaves the user with no context to know
what the answer refers to.
Add an option to keep some lines of context when using skip-quoted.
With skip_quoted_context set to 5, skip-quoted will show at most 5 lines
of the previous quote. If the previous quote is shorter than 5 lines the
whole quote will be displayed.
This option defaults to 0 to remain backwards compatible.
---
globals.h | 1 +
init.h| 9 +++
pager.c | 70 ++-
3 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/globals.h b/globals.h
index 859732e6..06ce410e 100644
--- a/globals.h
+++ b/globals.h
@@ -234,6 +234,7 @@ WHERE short HistSize;
WHERE short MenuContext;
WHERE short PagerContext;
WHERE short PagerIndexLines;
+WHERE short PagerSkipQuotedContext;
WHERE short ReadInc;
WHERE short ReflowWrap;
WHERE short SaveHist;
diff --git a/init.h b/init.h
index acc7d8b2..26784882 100644
--- a/init.h
+++ b/init.h
@@ -2386,6 +2386,15 @@ struct option_t MuttVars[] = {
** is less than $$pager_i
Re: [PATCH] Add skip_quoted_context option
On Mon, Jun 14, 2021 at 09:18:32AM -0300, Jim Diamond wrote: I think the idea is very useful. I rarely use skip-quoted because of the lack of context, and when I do use it I almost always back up a few lines. I wish I had thought of this patch years ago. Thank you for your feedback Jim and Aaron. It sounds like this would be a good feature, then. :-) I'll take a closer look at the patch in the next couple days. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: GPG list keys search strings
On Wed, Jun 02, 2021 at 05:53:25PM +0200, Werner Koch wrote:
On Mon, 31 May 2021 15:08, Kevin J. McCarthy said:
Both the classic and GPGME code perform a strtok(" ,.:\"()<>\n") call
on the email address and personal name fields and discard parts
smaller than 4. So searching for john@example.com will generate
I really don't know the origin. I don't have old versions of Mutt or my
old mail archives online anymore and thus can't check easily. I am
pretty sure it has always been there and I copied it only over to the
gpgme code.
Thank you Werner. I think the strtok() makes some sense when searching
against the personal field (to allow for missing middle names or
initials etc). But I can't think of any reason why this would be
desirable for matching against the email address.
Since I've just released 2.1, I think now is a good time to try somewhat
risky changes. I'm going to change it to directly add the email address
to the hints list.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] Add skip_quoted_context option
On Sun, Jun 13, 2021 at 03:56:58PM +0200, Rene Kita wrote:
Using skip-quoted the first unquoted line becomes the new top line
displayed in the pager. This leaves the user with no context to know
what the answer refers to.
I need to get through a backlog of other things before I look too
closely at this. However, I'd like others' opinions on the usefulness
of the option. My initial impression is that it's not generally useful
(i.e., if you need context then don't ) but I'd appreciate
others take.
Just glancing quickly, please watch the coding style. e.g.
while (test)
{
}
not
while (test){
}
+ while (!err && SkipQuotedContext > 0
It looks like the patch disables if $skip_quoted_context
is left at 0?
+ if (new_topline - context < 0)
+ context += new_topline - context;
Could that just be:
if (context > new_topline)
context = new_topline;
Lastly, I'd prefer the config var have "pager_" in front to give it
context. (Pun intended). e.e. $pager_skip_quoted_context.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
GPG list keys search strings
[Cc'ing Thomas and Werner since they probably have the best chance of
remembering something].
There's a gitlab ticket[1] inquiring about the search strings used when
searching for GPG keys. I've wondered about the behavior myself and
would appreciate any information on the reasoning if you can recall it.
:-)
Both the classic and GPGME code perform a strtok(" ,.:\"()<>\n") call on
the email address and personal name fields and discard parts smaller
than 4. So searching for john@example.com will generate two search
hints: 'john' and 'doe@example'.
Now, as I mention in the ticket, this has been the behavior for 20+
years and hasn't caused any issues that I'm aware of. So I'm not
itching to change it. But I would appreciate any help in explaining
it. Perhaps it helped in searching or prevented bugs.
Thank you!
[1] https://gitlab.com/muttmua/mutt/-/issues/354
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: [PATCH] fix gcc-11 build warnings for H_TO_INTL()
On Fri, May 28, 2021 at 02:23:37PM +0200, Greg Kroah-Hartman wrote: The macro H_TO_INTL() in mutt_idna.c, causes a lot of build warnings about the indentation of the if () line to try to warn the developer that it looks like this might be a bug: Applied. Thank you Greg! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [PATCH] Trim the ToC for the option list in the manual
On Fri, May 28, 2021 at 02:38:41PM +0300, Maxim Tarasov wrote: Currently, every variable is shown in the table of contents of the reference manual. Variable list is over 400 items long. This makes the ToC difficult to work with. Applied. Thank you Maxim! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Starting freeze for 2.1 release soon
Hi Everyone, I think it's about time to start working on the next release from master. Things have been quiet recently, so I'll plan on freezing this Friday May 28th. As usual I'll give two weeks for the translators to work on their updates and will plan on releasing the weekend of June 11-13th. I've started writing up the changes since last release, and will add those to the UPDATING file this week. There haven't been many huge user-visible features this cycle, but there were internal and infrastructure changes. So if you have the chance, please try building and running from the master branch to help shake out issues. Thank you, -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Loosening mailcap filename sanitization to allow unicode filenames
On Thu, Apr 29, 2021 at 09:25:39PM +0200, Vincent Lefevre wrote:
Concerning the ASCII characters, note that "{" and "}" may have a
special meaning for the shell.
And ":" may have a special interpretation in some applications
(e.g. scp, but maybe applications that support URL arguments).
I also wonder whether "%" should be forbidden, unless you know that
it comes from percent-encoding.
Thanks Vincent. I'm reluctant to make changes to the sanitizer without
reports of issues. The Mutt code wraps the expandos in single quotes,
and launches it via /bin/sh. So, I'm not really clear about the purpose
of the sanitizer, unless it was to help protect against misuse by the
mailcap program invoked.
But I'm also not ready to remove the sanitizer either, because there
isn't any historical justification that I can find, and I'm absolutely
*not* a security person myself... :-/
Note also that "-" should not be used as the first character of
a filename, otherwise it could be confused with an option.
Fortunately, the filename is appended to the tmpdir, so a leading hyphen
should be okay.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: Loosening mailcap filename sanitization to allow unicode filenames
On Tue, Apr 27, 2021 at 06:16:59PM -0700, Kevin J. McCarthy wrote: Answering the question first, Mutt will decode the RFC2231 parameters and convert them to $charset. It looks like the 2231 decoder does run values through mutt_filter_unprintable(). I'm looking closer at the 2231 decoder and it actually looks like it doesn't always do this. I think that was a mistake, and I'll add a fix. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Loosening mailcap filename sanitization to allow unicode filenames
On Wed, Apr 28, 2021 at 01:44:03AM +0200, Eike Rathke wrote: On Tuesday, 2021-04-27 10:17:29 -0700, Kevin J. McCarthy wrote: What if we added an allow_8bit parameter to the function, that also passed through bytes with the 8th bit set? I'd keep this set off in all other invocations except the mailcap invocations. Allowing *all* 8-bit may be ill advised. I'd disallow at least resulting U+0080 to U+009F Unicode control characters (C1 control codes). Also exclude the non-characters U+FFFE and U+. But, what text encoding are we actually talking about? Answering the question first, Mutt will decode the RFC2231 parameters and convert them to $charset. It looks like the 2231 decoder does run values through mutt_filter_unprintable(). mutt_filter_unprintable() calls mbrtowc() to check for a valid sequence and then iswprint() to ensure the character is in the "print" class. For the first part, I *think* that addresses your concern. But in any case, would those characters cause issues for a tempfile filename? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Loosening mailcap filename sanitization to allow unicode filenames
On Wed, Apr 28, 2021 at 08:48:04AM +1000, Cameron Simpson wrote: On 27Apr2021 10:17, Kevin J. McCarthy wrote: First remark: I think we should make clear that this only makes sense when you're encoding filenames as UTF-8, where all multibyte sequences have a high bit set. This isn't necessarily the case with other encodings. I was under the impression other encodings at least shared the standard printable ascii 7-bit characters, and that other characters (whether single or multi-byte) had the high bit set to distinguish them. However, charsets are definitely an area I'm weak on. Second remark: As one who has long been less than enthused by sanitising filenames, what exactly are we trying to accomplish when we sanitise a filename? - avoid trickiness like whitespace and quote characters, which cause a little pain for users of the files in scripting settings? - avoiding $ and ` et al, which cause hazards for the very careless script author? (but inly if injected blindly) - avoiding other shell punctuation like redirections? same issue - avoiding escape paths such as absolute paths (/etc/passwd, oh root-run mutt user?) or ../blah to get out of the scratch area? Without qualifying these objectives, "sanitisation" means little (or too much, depending where you stand). If I had to guess, I would say all of the above. But, unfortunately the code and sanitization is 20+ years old, so I think you'd have to check with Michael or Thomas to get the exact details of why. :-) They did leave a big bold faced warning in the $mailcap_sanitize manual documentation not to turn it off though. On the one hand these are temp files, but Mutt already tries to preserve the filename to make for a nicer user interaction. It seems if we can preserve unicode filenames better we ought to do that too. "Unicode filenames" isn't a meaningful term in UNIX, as the API is C strings - byte sequences with NUL terminators. I suspect you mean "UTF-8 encoded names", which is the common modern default. Sorry for my sloppiness. I should have said to "preserve high-bit bytes in filenames." The filename parameter arrives in RFC2231 encoding, which includes a charset parameter. Mutt will decode and convert this value to the machine charset (or $charset if that's specified). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Loosening mailcap filename sanitization to allow unicode filenames
Ticket 351 on gitlab (https://gitlab.com/muttmua/mutt/-/issues/351)
noted that an attachment 中文名称.txt, when launched via a mailcap
viewer, created a tempfile ".txt".
This is because of the sanitize_filename() functions, which have an
allow-list of
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+@{}._-:%/"
(with the '/' disabled for filenames).
I'd be reluctant to change sanitization for the %{} or %t
expandos, but this does seem to be a bit strict for the filename.
Oswald notes in the ticket that 8-bit characters are harmless at the
system level (Oswald, feel free to reply/clarify - I'm not trying to put
words in your mouth).
On the one hand these are temp files, but Mutt already tries to preserve
the filename to make for a nicer user interaction. It seems if we can
preserve unicode filenames better we ought to do that too.
What if we added an allow_8bit parameter to the function, that also
passed through bytes with the 8th bit set? I'd keep this set off in all
other invocations except the mailcap invocations.
Comments?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: SHA-1 usage
On Fri, Mar 19, 2021 at 11:10:22AM +0100, Filip Janus wrote: I am the maintainer of Mutt package in Fedora and RHEL. I would like to ask, how Mutt deal with the SHA-1 hash algorithm. The TLS Cert prompts show SHA256 and SHA-1 hashes now. I don't think there are any places we default to SHA-1 only, but if I missed something please someone reply. I found the default usage of sha-1 in the file crypt-gpgme.c . No, I don't believe that is the case. GPGME attempts to find the hash algorithm used in the signature. The comments says *older* versions of GPGME didn't support obtaining that value for S/MIME and so it assumed the signature was made using SHA-1. Mutt isn't actually *using* SHA-1 here, and recent GPGME should give us the actual value. So my question is, is there the ability to drop SHA-1 or force Mutt to use sha256 everywhere? The contrib/smime.rc specifies sha256 for classic mode (i.e. direct invocation of openssl). There is no Mutt configuration value for gpg settings. I believe that is controlled via the gpg.conf file. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: $ssl_client_cert users?
On Sat, Mar 06, 2021 at 09:09:35AM -0800, Kevin J. McCarthy wrote: Is anyone here using $ssl_client_cert to authenticate to a IMAP/POP/SMTP server? TL;DR: if so, please help me test against branch `kevin/336-smtp-client-cert`. I've merged the branch into master. Again, if you notice any problems with client cert authentication as a result, please holler. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
$ssl_client_cert users?
Is anyone here using $ssl_client_cert to authenticate to a IMAP/POP/SMTP server? TL;DR: if so, please help me test against branch `kevin/336-smtp-client-cert`. Gitlab #336 <https://gitlab.com/muttmua/mutt/-/issues/336> reported a problem using this for authentication to a Postfix SMTP server. The problem seemed to be the OpenSSL / GnuTLS client cert code was calling mutt_account_getuser(). First this makes no sense (to me) because they are authenticated via cert. But second, if the user is set, the SMTP code would then force authentication. The server didn't advertise AUTH (again, because they are already authenticated), so Mutt would abort. I've posted a still work-in-progress commit to branch `kevin/336-smtp-client-cert` which fixes the issue for the reporter. However, I'm concerned this *might* impact other use cases. It's not clear to me how/why SASL "external" would be involved in this. But the comment in the SSL/GnuTLS code indicated it could be, and might expect the user field. It would seem to me more obvious to just add the call to the beginning of imap_auth_sasl() if that's the case though. :-/ Anyway, if you are using this, I'd appreciate help testing. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Updating gettext autoconf macros to 0.21
On Sat, Feb 20, 2021 at 03:16:17PM -0800, Kevin J. McCarthy wrote: I'll merge the branch into master tomorrow, but if anyone has the time please give it a test. I've merged the branch into master. As before, please let me know if you find any problems. Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Updating gettext autoconf macros to 0.21
On Sun, Feb 21, 2021 at 10:06:32AM +0100, Rene Kita wrote: On Sat, Feb 20, 2021 at 03:16:17PM -0800, Kevin J. McCarthy wrote: I've help menu fixes to branch 'kevin/gettext-bugs-v2' on gitlab. (NOTE: this is a different branch from before.) [...] I'll merge the branch into master tomorrow, but if anyone has the time please give it a test. After getting my configure options straight I can confirm that the help text is now translated (and was not translated before). Great, thanks for help testing it! The PO file machinery can be tricky to test, and I'm not all that familiar with their intricacies myself either. So I appreciate the help. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Updating gettext autoconf macros to 0.21
I've help menu fixes to branch 'kevin/gettext-bugs-v2' on gitlab. (NOTE: this is a different branch from before.) This branch generates the help menu translation strings directly from the OPS files. I recommend performing a 'make maintainer-clean' and then running './prepare [your options]' to ensure you work from a clean environment. I'll merge the branch into master tomorrow, but if anyone has the time please give it a test. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Updating gettext autoconf macros to 0.21
On Sat, Feb 20, 2021 at 06:51:44PM +0100, Vincent Lefevre wrote: I don't understand how you can get the same gmo file since in ccc18061, the dependency on the OPS* file is gone. As an update, I'm working on a fix to directly generate the translation strings from the OPS* files. I should have that pushed up this weekend. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Updating gettext autoconf macros to 0.21
On Fri, Feb 19, 2021 at 02:00:51AM +0100, Vincent Lefevre wrote: An important change is: diff --git a/po/POTFILES.in b/po/POTFILES.in index c7fdd935..62329627 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -44,6 +44,7 @@ imap/util.c init.c init.h keymap.c +keymap_alldefs.h lib.c listmenu.c main.c Indeed, I suppose that without keymap_alldefs.h in POTFILES, the associated translations are ignored. Just as an update, I'm still working on this. The fixes in the branch (including the above) did "fix" things when building out of git, but fail with a separate src and build directory. The gettext manual helpfully suggests to just not use generated files for input :-). So this is probably why the customization occurred in the past. Please let me work on this over the weekend to see what I can come up with. I'd rather not revert, because the issue will hang over Mutt in the future... -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
