Re: Ctrl-C / SIGINT behavior

On 2023-12-12 15:17:29 -0500, Derek Martin wrote: > On Wed, Dec 06, 2023 at 03:10:11PM +0100, Vincent Lefevre wrote: > > The behavior of SIGINT (typically generated by Ctrl-C in the terminal) > > is not documented. > > > > It currently asks whether to exit, w

Ctrl-C / SIGINT behavior

The behavior of SIGINT (typically generated by Ctrl-C in the terminal) is not documented. It currently asks whether to exit, with MUTT_YES as the default: /* this function is called when the user presses the abort key */ void mutt_query_exit (void) { mutt_flushinp (); curs_set (1); if

Re: [PATCH] Change default message-id format.

On 2023-03-07 15:15:22 -0800, Kevin J. McCarthy wrote: > However, I don't have the time or interest to participate in another > message-id bike shedding discussion, and don't plan on changing the > default format in the stable branch. Anyway, the message-id format is configurable with

does not honor my_hdr

It appears that does not honor my_hdr. I don't think this is the right behavior, or perhaps this could be configurable. The issue is that I have "my_hdr Bcc: ..." to send of a copy of the message to myself, but since "Bcc:" is not kept in sent messages (for privacy reasons) and my_hdr is not

Re: [pager] line wrapping breaks URL detection

On 2022-05-13 21:55:12 +0200, Daan van Rossum wrote: > * on Friday, 2022-05-13 19:49 +0200, Vincent Lefevre > wrote: > > A better tool could be to convert the text to HTML with just > > URL recognition to generate URL links (and > > perhaps a bit more

Re: [pager] line wrapping breaks URL detection

On 2022-05-13 21:55:12 +0200, Daan van Rossum wrote: > There is the 'urlscan' tool that does exactly this. It does the job, > without using the terminal's url detection functionality. I didn't know it. Mutt's manual mentions "urlview". So I think that it should mention "urlscan" too. -- Vincent

Re: [pager] line wrapping breaks URL detection

On 2022-05-13 20:25:28 +0200, Magnus Groß wrote: > Mutt could also use OSC 8 [1] to embed the link directly. This would work > regardless of whether mutt inserts hardcoded linebreaks or not. > > For example the following works despite the linebreak inbetween (tested in > wezterm): > >

Re: [pager] line wrapping breaks URL detection

On 2022-05-13 18:49:04 +0200, Gero Treuner wrote: > Good point. There is the good old urlview program, also mentioned in the > Mutt manual: > https://github.com/sigpipe/urlview > > It can start a browser, but doesn't present URLs ready for copy. So this > could be a new feature or a new tool.

Re: Moving towards an eventual 2.3.0

On 2022-02-22 19:01:34 -0800, Kevin J. McCarthy wrote: > - #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. FYI, in 2008, I wrote a patch to search for an address in h->env->from,

Re: Upcoming freeze for 2.2.0 and maintainer update

On 2022-01-28 15:48:39 +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 goo

Re: Upcoming freeze for 2.2.0 and maintainer update

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 cor

Re: Upcoming freeze for 2.2.0 and maintainer update

On 2022-01-23 09:47:57 -0800, Kevin J. McCarthy wrote: > 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 >

Re: $reply_prefix

On 2022-01-14 14:36:13 +0300, Jean Louis wrote: > * Vincent Lefevre [2022-01-14 12:20]: > > On 2022-01-14 11:05:14 +0300, Jean Louis wrote: > > > I do not see anything that is "against" the RFC5322. > > > > You misread it. See my othe

Re: Mutt on ubuntu 20

On 2022-01-14 14:30:40 -0600, Derek Martin wrote: > On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote: > > On 2022-01-13 15:36:04 -0600, Derek Martin wrote: > > > So... The only difference between this and hdrdefault is that > > > hdrdefault's order does

Re: $reply_prefix

On 2022-01-14 11:05:14 +0300, Jean Louis wrote: > I do not see anything that is "against" the RFC5322. You misread it. See my other replies. > It MAY, and it MAY NOT. There is no strict rule to it. Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden. But this does not mean that

Re: $reply_prefix

On 2022-01-14 09:49:12 +0100, Fredrik Gustafsson wrote: > That's already the case. For example in Sweden, "Sv:" is used instead of > "Re:". This is not a mutt decision and > the decision is already made for us. We can like it or dislike it. Fortunately most people do not use it. In my mail

Re: $reply_prefix

On 2022-01-14 09:10:19 +0200, Tapani Tarvainen wrote: > On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us) > wrote: > > > I've been told other prefixes are often used in some lists, and the > > practice is getting more common. > > Other prefixes have also long been used

Re: $reply_prefix

On 2022-01-13 21:25:27 -0800, Kevin J. McCarthy wrote: > On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote: > > 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"

Re: $reply_prefix

On 2022-01-13 19:41:12 -0800, Will Yardley wrote: > On Thu, Jan 13, 2022 at 09:42:27PM -0500, John Hawkinson wrote: > > Although my personal preference is that this is not a knob Mutt needs, > > I am cognizant that some other popular MUAs use "RE: " rather than > > "Re: " and while that looks

Re: $reply_prefix

On 2022-01-14 03:26:36 +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

Re: Mutt on ubuntu 20

On 2022-01-13 15:36:04 -0600, Derek Martin wrote: > So... The only difference between this and hdrdefault is that > hdrdefault's order does not matter. This is a very minor difference, > and the distinction disappears so long as you provide the "." rule > first, This would mean that it would

Re: Mutt on ubuntu 20

On 2022-01-12 14:40:38 -0600, Derek Martin wrote: > FWIW (particularly with this fixed) I think hdrdefault is redundant, I don't think it is. IMHO, hdrdefault means the color when no other rules match. If you use "color header ... .", it would override other rules earlier in the list. --

Re: [PATCH] Option to clear the screen on quit

On 2021-11-09 17:42:57 -0600, Derek Martin wrote: > On Tue, Nov 02, 2021 at 07:10:24PM +0100, Petr Pisar wrote: > > V Mon, Nov 01, 2021 at 11:44:25AM +1100, Cameron Simpson napsal(a): > > For that purposes I added ^[3J sequence into Linux 3.0 which erases not only > > whole display but also a

Re: [PATCH] Option to clear the screen on quit

On 2021-10-29 14:19:29 -0500, Derek Martin wrote: > On Wed, Oct 27, 2021 at 05:10:35PM +0200, Vincent Lefevre wrote: > > I was wondering whether this could occur when switching to the > > alternate screen. But it seems that this is not the case, at least > > not with Xt

Re: [PATCH] Option to clear the screen on quit

On 2021-10-25 14:44:32 -0500, Derek Martin wrote: > There is an ANSI escape sequence to tee data to your printer, sure... > but it can not be used retroactively copy data that is on your > terminal to the printer. It just copies data that is currently being > displayed (i.e. since the sequence

Re: [PATCH] Option to clear the screen on quit

On 2021-10-22 10:30:43 -0700, Kevin J. McCarthy wrote: > 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 > > al

Re: ctime, POSIX and ISO C

On 2021-10-22 10:13:01 -0700, Kevin J. McCarthy wrote: > 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 > >

Re: [PATCH] Option to clear the screen on quit

On 2021-10-17 09:35:26 -0700, Kevin J. McCarthy wrote: > 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

ctime, POSIX and ISO C

About the following commit: commit 60ab5f117d813b6ea7bdd6dacc1a771ea63edc6d Author: Kevin McCarthy Date: 2021-10-20 03:48:47 +0200 Add internal mutt_ctime() implementation. ctime() is marked obsolescent in the POSIX guide, so we ought to stop using it to ensure future

Re: [PATCH] Option to clear the screen on quit

On 2021-10-17 19:40:19 -0500, Oskari Pirhonen wrote: > I had mistakenly assumed which(1) was in coreutils, which would be fine > for reasonably portable scripts. Note that under Debian/unstable, /usr/bin/which now gives a warning: /usr/bin/which: this version of `which' is deprecated; use

Re: strfcpy in dotlock.c

On 2021-07-22 09:11:56 -0700, Kevin J. McCarthy wrote: > What do you think of using memccpy in the strfcpy macro, IMHO, it is better than strncpy, which unnecessarily pads with null bytes. > if it's available, as Ian suggested? The Linux memccpy(3) man page says: CONFORMING TO

strfcpy in dotlock.c

Concerning the commit commit 8970a4793c302c0bb8619a5dde56c8ca8de20532 Author: Kevin McCarthy Date: 2021-07-21 22:26:25 +0200 Silence strfcpy() warning in dotlock_deference_symlink(). The compiler is being a bit strange, only picking out and warning about the 'strfcpy (d,

Re: Loosening mailcap filename sanitization to allow unicode filenames

On 2021-04-29 18:24:30 -0700, Kevin J. McCarthy wrote: > Thanks Vincent. I'm reluctant to make changes to the sanitizer without > reports of issues. Old MacOS versions seem to forbid ":" (colon):

Re: Loosening mailcap filename sanitization to allow unicode filenames

On 2021-04-27 10:17:29 -0700, Kevin J. McCarthy wrote: > 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,

Re: Updating gettext autoconf macros to 0.21

On 2021-02-21 14:58:06 -0800, Kevin J. McCarthy wrote: > 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

Re: Updating gettext autoconf macros to 0.21

On 2021-02-21 09:50:06 +0100, Rene Kita wrote: > 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. > Because I diffed the _output_ of the help

Re: Updating gettext autoconf macros to 0.21

On 2021-02-20 12:48:33 +0100, Rene Kita wrote: > On Thu, Feb 18, 2021 at 11:28:02PM +0100, Vincent Lefevre wrote: > > The messages in the help are no longer translated, e.g. previously: > > > > [...] > > ^N next-threadaller à la discussion suivan

Re: Updating gettext autoconf macros to 0.21

On 2021-02-18 16:27:26 -0800, Kevin J. McCarthy wrote: > On Thu, Feb 18, 2021 at 03:54:17PM -0800, Kevin J. McCarthy wrote: > > I'm still working on the help screen issue. The dependency was a > > problem, and I believe I've worked around that. However, I'm still > > getting the missing

Re: Updating gettext autoconf macros to 0.21

On 2021-02-18 16:27:26 -0800, Kevin J. McCarthy wrote: > The problem went away when I force rebuilt everything, including > po/mutt.pot. I still need to investigate more what's going on, because I > think something it not right. > > I've pushed a branch to 'kevin/gettext-bugs' with two

Re: Updating gettext autoconf macros to 0.21

On 2021-02-19 00:38:11 +0100, Vincent Lefevre wrote: > I've reverted the change. With 0.21 as the version, this makes > autoreconf fail on Debian stable because gettext is too old. > But gettext 0.21 isn't really required. Lowering the version > e.g. to 0.19 makes autopoint fail with

Re: Updating gettext autoconf macros to 0.21

On 2021-02-19 00:04:20 +0100, Vincent Lefevre wrote: > I've just pushed a commit that does that (with 0.21 as the version): > the warning has disappeared. I've reverted the change. With 0.21 as the version, this makes autoreconf fail on Debian stable because gettext is too old. But gettex

Re: Updating gettext autoconf macros to 0.21

On 2021-02-18 14:53:24 -0800, Kevin J. McCarthy wrote: > On Thu, Feb 18, 2021 at 11:28:02PM +0100, Vincent Lefevre wrote: > > A minor issue: autoreconf gives: > > > > autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not > > AM_GNU_GETTEXT_VERSION > > I di

Re: Updating gettext autoconf macros to 0.21

On 2021-02-18 23:28:02 +0100, Vincent Lefevre wrote: > The messages in the help are no longer translated, e.g. previously: > > [...] > ^N next-threadaller à la discussion suivante > ^P previous-threadaller à la discussion précédente > [...]

Re: Updating gettext autoconf macros to 0.21

Hi, On 2021-02-18 13:37:17 -0800, Kevin J. McCarthy wrote: > On Wed, Feb 17, 2021 at 04:00:19PM -0800, Kevin J. McCarthy wrote: > > I'm going to merge and push the branch up to master tomorrow. Please > > let me know if you see any problems (either before or after the merge). > > I've merged

message_id_format

Hi, ** .dt %y .dd current year using 4 digits (GMT) Any reason not to follow the same notation as strftime() for the year? For the 4-digit year, I would rather expect %Y. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: Change Message-ID generation to be more unique and leak less information

On 2021-01-11 08:22:08 +, Eric Wong wrote: > Derek Martin wrote: > > On Sat, Jan 09, 2021 at 10:54:28PM +, Eric Wong wrote: > > > Hi Remco, > > > > > > So I'm looking at 9da4e6e11e7037668d0ca7e8f5d6773d26e379ac > > > (I noticed this in mutt 2.0.2 on FreeBSD) > > > > > > This is a bad

Re: [PATCH] Support for overriding permissions of saved files

On 2020-08-11 22:29:41 -0500, Derek Martin wrote: > On Wed, Aug 12, 2020 at 02:40:16AM +0200, Vincent Lefevre wrote: > > On 2020-08-06 18:40:50 -0500, Derek Martin wrote: > > > Are you serious, Vincent? I'm pretty sure you well know that this is > > > a horrible ide

Re: [PATCH] Support for overriding permissions of saved files

On 2020-08-06 18:40:50 -0500, Derek Martin wrote: > Are you serious, Vincent? I'm pretty sure you well know that this is > a horrible idea, clearly contrary to best security practices, that no > competent sysadmin managing servers holding anything vaguely sensitive > would ever allow on a

Re: [PATCH] Support for overriding permissions of saved files

On 2020-08-06 10:50:23 -0500, Derek Martin wrote: > On Wed, Jul 29, 2020 at 12:55:07PM -0500, Derek Martin wrote: > > On Tue, Jul 28, 2020 at 08:03:23PM +0200, sacham...@s0c4.net wrote: > > > The thread, and even older threads referenced there, is from 2007. > > > Since then, the security field

Re: [PATCH] Add support for DT_R(UN)PATH in ELF executables.

On 2020-07-29 13:19:31 -0500, Derek Martin wrote: > On Tue, Jul 28, 2020 at 12:59:55AM +0200, Mono DHS wrote: > > Subject says it all > > What is the motivation for this patch? > > My initial reaction is this patch adds a bunch of configure code that > will be used by pretty close to no one, so

Re: [PATCH] Fix man section in reference to mutt_dotlock

On 2020-07-29 11:55:46 -0500, Derek Martin wrote: > On Sun, Jul 26, 2020 at 03:04:33AM +0300, Maxim Tarasov wrote: > > --- > > init.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/init.h b/init.h > > index 06d4cc9a..f0d2c697 100644 > > --- a/init.h > > +++

Re: [PATCH] Change hardcoded subject of replies

On 2020-07-25 00:20:22 +0300, Maxim Tarasov wrote: > Here are some other things to consider about "Re:" > > 1) It is recognized by RFC5322: > > When used in a reply, the field body MAY start with the > string "Re: " (an abbreviation of the Latin "in re", meaning "in the > matter of")

reply-hook and Subject (was: [PATCH] Change hardcoded subject of replies)

On 2020-07-24 09:42:06 -0700, Kevin J. McCarthy wrote: > On Fri, Jul 24, 2020 at 05:03:09PM +1200, Tom Ryder wrote: > > On Fri, Jul 24, 2020 at 06:56:38AM +0200, Claus Assmann wrote: > > > > Would you or Maxim consider making it a _("translatable > > > > string")---or perhaps even better, a

Re: CVE status and regression in 1.14.3 release

On 2020-06-21 17:54:56 -0700, Kevin J. McCarthy wrote: > I'm inclined to take the stance that the $tunnel is secure. For stable > branch, I'll include the PREAUTH patch in <20200621151915.gg23...@afu.lan>: > if (!idata->conn->ssf && !Tunnel && option(OPTSSLFORCETLS)) > but make no other

Re: CVE status and regression in 1.14.3 release

On 2020-06-21 10:59:05 -0700, Kevin J. McCarthy wrote: > On Sun, Jun 21, 2020 at 07:29:58PM +0200, Vincent Lefevre wrote: > > Well, there's still something that isn't clear. When the user uses the > > "imaps" protocol, I assume that the connection needs to be encrypte

Re: CVE status and regression in 1.14.3 release

On 2020-06-21 08:19:15 -0700, Kevin J. McCarthy wrote: > This has been a bad week and I'm tired. Sorry, I understand your point now. > > I think you are right. I'm protecting against *nothing* by inserting a > $ssl_starttls prompt for "* PREAUTH" because the MITM can just as easily > insert "*

Re: CVE status and regression in 1.14.3 release

On 2020-06-20 14:49:56 -0700, Kevin J. McCarthy wrote: > Hello Mutt Users, > > Please pardon the "non-announcement" use of this list. I generally try to > keep the noise to a minimum, but felt this update was needed. > > The 1.14.3 release, fixing a possible IMAP PREAUTH injection attack, had a

IMAP: Abort unencrypted PREAUTH connection

Hi, The following in imap/imap.c is not clear about the security implications: /* An unencrypted PREAUTH response is most likely a MITM attack. * Require a confirmation unless using $tunnel. */ If I understand correctly, this cannot be a MITM attack if $tunnel is used (perhaps PREAUTH

Re: mutt 1.14.4 released

On 2020-06-20 09:39:04 +0200, Petr Pisar wrote: > On Sat, Jun 20, 2020 at 01:39:21AM +0200, Vincent Lefevre wrote: > > On 2020-06-20 08:48:04 +1000, Cameron Simpson wrote: > > > On 19Jun2020 07:11, Kevin J. McCarthy wrote: > > > >On Fri, Jun 19, 2020 at 09:48:32A

Re: mutt 1.14.4 released

On 2020-06-20 08:48:04 +1000, Cameron Simpson wrote: > On 19Jun2020 07:11, Kevin J. McCarthy wrote: > >On Fri, Jun 19, 2020 at 09:48:32AM +0200, Vincent Lefevre wrote: > >>On 2020-06-18 18:14:15 -0700, Kevin J. McCarthy wrote: > >>+/* L10N: > >>+ The

Re: mutt 1.14.4 released

On 2020-06-18 18:14:15 -0700, Kevin J. McCarthy wrote: > This is an important security release fixing a possible > machine-in-the-middle response injection attack when using STARTTLS with > IMAP, POP3, and SMTP. (For packagers, I've requested a CVE and will update > the website when I have the

[PATCH] Rocco's colored progress bar patch

Another patch I like very much is Rocco's colored progress bar patch: http://marc.info/?l=mutt-dev=123730077818672 Updated version attached. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer

Re: Help for pattern modifiers

On 2020-06-15 19:37:21 -0700, Kevin J. McCarthy wrote: > On Mon, Jun 15, 2020 at 12:34:50PM -0500, Corey Minyard wrote: > > I have a bookmark set to http://www.mutt.org/doc/manual/#patterns > > because, well, I can't remember all those patterns. I was wondering if > > a command could be added so

message "Mailbox reconnected."

Hi, For the translation: #. L10N: #. Message printed on status line in index after mx_check_mailbox(), #. when IMAP has an error and Mutt successfully reconnects. #. #: curs_main.c:710 msgid "Mailbox reconnected. Some changes may have been lost." msgstr "" I have a problem with this message. I

Re: locking mechanism

On 2020-05-12 12:38:52 -0700, Kevin J. McCarthy wrote: > On Tue, May 12, 2020 at 02:43:44AM +0200, Vincent Lefevre wrote: > > * one should be able to specify the location of the dotlock program > >at run time (so that non-root users could install a more recent > &g

Re: locking mechanism

On 2020-05-11 20:38:19 +0200, Steffen Nurpmeso wrote: > Vincent Lefevre wrote in > <20200510204809.ga71...@zira.vinc17.org>: > |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is > |dotlocking still used nowadays? > > I find yes. Or at least last i l

Re: locking mechanism

On 2020-05-11 00:31:43 +0200, Moritz Barsnick wrote: > Haha, I still have one message in that thread from 15 years ago marked > as "unread". It was one of the first threads after I subscribed to this > list. I stumbled back upon it while checking since when Redhat had > patched mutt's dotlocking

locking mechanism

Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is dotlocking still used nowadays? Even if it is, I find annoying that for an end user who probably won't need it, Mutt's installation will fail if he does not provide the --with-homespool option. Let's recall that dotlocking alone is

missing translations in exit_handler (signal caught)

When Mutt quits due to a signal, I get, e.g. Caught signal 3... Exiting. untranslated. The reason it is not translated is that _() can invoke malloc(), which may not be re-entrant. Note that this was fixed by Kevin on 2019-11-10. Translations were done in the past, and with ^\ (SIGQUIT), Mutt

Re: Use curses' raw instead of cbreak mode to capture \C[cyz\]

On 2020-05-07 13:13:49 +0200, Gero Treuner wrote: > I don't think that raw mode per se changes the terminal configuration. It necessarily does at some point. I suppose that this is like "stty raw", which is described as: rawsame as -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr

Re: Use curses' raw instead of cbreak mode to capture \C[cyz\]

hich is actually triggered by Ctrl-G instead of Ctrl-C. Moreover, it can itself act as a terminal (even when started as an editor). > On Thu, May 07, 2020 at 03:57:37AM +0200, Vincent Lefevre wrote: > > > On my Mutt pages https://www.vinc17.net/mutt/index.en.html > > I mention a lit

Re: Use curses' raw instead of cbreak mode to capture \C[cyz\]

On 2020-05-06 11:44:06 +0200, Christopher Zimmermann wrote: > Hello dear mutt developers, > > I prepared a merge request that needs some consideration. > > Why? I use mutt on OpenBSD with heavily customized vi-like key bindings and > colouring. Especially I'm used to line-wise scrolling being

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-26 23:32:38 +0200, Gero Treuner wrote: > Hi Vincent, > > On Sun, Apr 26, 2020 at 10:51:51PM +0200, Vincent Lefevre wrote: > > On 2020-04-26 02:33:00 +0200, Gero Treuner wrote: > > > The MessageId still starts with the time, but is now included in the &

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-26 02:33:00 +0200, Gero Treuner wrote: > The MessageId still starts with the time, but is now included in the > base64 part, joined with the random section before encoding. Why is the time needed? Since you use a CSPRNG, you can just use random data for the full local part of the

Re: consistency in message strings

On 2020-04-24 10:28:17 -0500, Derek Martin wrote: > On Fri, Apr 24, 2020 at 09:57:59AM -0500, Derek Martin wrote: > > This is not completely accurate, at least under US law. If you keep a > > mix of old and new content, your copyright date may be a range of > > years instead of a single year.

Bytes size display

I have a couple of remarks about "Bytes size display". There should be an option so that the unit "K" is not displayed when $size_show_bytes is unset. Or perhaps it should never be displayed in this case (i.e. no displayed unit = default unit). In particular, the "K" is a waste of space when both

Re: consistency in message strings

On 2020-04-23 13:29:54 -0500, Derek Martin wrote: > On Mon, Apr 20, 2020 at 08:09:08PM +0200, ilf wrote: > > I think it's fair to honor Kevin as maintainer more than "others". > > I would propose something along: "Copyright (C) 1996-2016 Michael > > R. Elkins, 20XX to 2020 Kevin J. McCarthy, and

Re: exact address: broken with utf-8 encoding

On 2020-04-23 09:47:08 +0200, Claus Assmann wrote: > On Wed, Apr 22, 2020, Kevin J. McCarthy wrote: > > > I think I would prefer to make "exact address" deprecated in 1.14 and remove > > it for 1.15. > > Then I would not upgrade to 1.15 (not that anyone would care...) > > I hate it if a program

Re: exact address: broken with utf-8 encoding

On 2020-04-23 09:07:32 +0200, Gero Treuner wrote: > In general I suggest to consider distributions, giving them an > opportunity to not miss the deprecated message to users within their > next release cycle before execution. That leads to 2-3 years resp. more > than 1 release of Mutt (for cases

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-22 18:37:09 -0700, Kevin J. McCarthy wrote: > On Wed, Apr 22, 2020 at 09:05:28PM -0400, re...@webconquest.com wrote: > > On Mon, Apr 20, 2020 at 11:18:55AM +0200, Oswald wrote in > > > you're leaking the random strings. i suggest passing in fixed-size > > > buffers instead. > > > > I

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-22 21:00:44 -0400, re...@webconquest.com wrote: > On Tue, Apr 21, 2020 at 09:54:17AM +0200, Gero wrote in > <20200421075417.gv11...@innocircle.com>: > > > One thing, though: use base36, not base64 - as recommended in [0]. > > > Base64 only saves 4 characters and you don't necessarily

Re: consistency in message strings

On 2020-04-22 20:34:18 -0400, re...@webconquest.com wrote: > Maybe add a line pointing to the COPYRIGHT file or perhaps a link to > somewhere on the website? It already does by mentioning "mutt -vv". > I was thinking perhaps an option would be to look at the number of lines > contributed, but

Re: exact address: broken with utf-8 encoding

On 2020-04-22 14:45:35 +0200, Claus Assmann wrote: > On Thu, Feb 27, 2014, Claus Assmann wrote: > > When replying to an address that used an utf-8 encoded name, e.g., > > > > From: =?utf-8?B?U2VuZGVyIFfDpGNoCg==?= > > > > mutt turned this into > > > > To: Sender

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-21 23:21:14 +0100, Ian Collier wrote: > On Tue, Apr 21, 2020 at 11:16:03PM +0200, Vincent Lefevre wrote: > > This is a user-side problem. Users should make sure that their > > hostname setting is unique (possibly with a very high probability, > > assuming n

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-20 21:49:11 +0100, Ian Collier wrote: > On Mon, Apr 20, 2020 at 07:08:07PM +0200, Gero Treuner wrote: > > The concern is that the inputs based on local and/or private information > > can be leaked. To achieve this the search space must be big enough. > [heavily snipped, of course] > >

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-20 19:57:23 +0200, Gero Treuner wrote: > This is necessary to stay on the deterministic track: For this we > require that different Mutt instances use information which differs by > the pid and time/sequence number at some point, which is the data fed to > the hash algorithm. OK, that

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-20 21:56:43 +0200, Arnt Gulbrandsen wrote: > I chose to hash in a similar situation. Basically I pass the entire message > through MD5 or another hash, then base64. > > A proper hash (even MD5) is indistinguishable from pure randomness if you > have no knowledge of the input, and

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-20 19:08:07 +0200, Gero Treuner wrote: > On Mon, Apr 20, 2020 at 05:57:00PM +0200, Vincent Lefevre wrote: > > But why not using a cryptographic hash for the full local part, then? > > This could be based on the full message (including the generated > > headers

Re: consistency in message strings

On 2020-04-20 09:14:22 -0700, Kevin J. McCarthy wrote: > On Mon, Apr 20, 2020 at 04:13:08PM +0200, Vincent Lefevre wrote: > > BTW, about copyright years, "mutt -v" says: > > > > [...] > > Copyright (C) 1996-2016 Michael R. Elkins and others. > > [...] &

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-19 07:38:39 -0400, Remco Rijnders wrote: > On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek wrote in > <20200419021334.go19...@bladeshadow.org>: > > OK I'm getting pretty bored with this, it's already been decided by > > Kevin it won't be accepted, but I'll answer this last message since

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-18 13:12:02 -0500, Derek Martin wrote: > And let's be clear about what it would take to generate messages with > the same ID in Mutt: > > - You need to generate > 26 messages in the same second--not any one >second, but XX:XX:XX.00 - XX:XX:XX.99. This is actually very >

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-19 16:34:57 +0200, Gero Treuner wrote: > For the small purpose of avoiding collisions within a time frame of 1s > a couple of extra bytes are comparatively high cost IMO. > > But you are right, and the timestamp could also be base64-ified to > compensate. But why not using a

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On 2020-04-19 17:35:50 -0400, Remco Rijnders wrote: > For the same future consideration, please find attached a proposed patch. > Deterministic it is not (unless you want to save the seed and a message > counter somewhere), guaranteed to be unique, it is. Well... If you have +#if RAND_MAX/256 >=

Re: consistency in message strings

On 2020-04-19 19:03:19 -0700, Kevin J. McCarthy wrote: > On Mon, Apr 20, 2020 at 03:47:51AM +0200, Vincent Lefevre wrote: > > I have noticed a lack of consistency in message strings: > > * "GPG key" vs "gpg key" (this should be "GPG key")

consistency in message strings

Hi, I have noticed a lack of consistency in message strings: * "GPG key" vs "gpg key" (this should be "GPG key") * "compose session" vs "editing session" Moreover, I think that "autocrypt" should be written with a capital letter (Autocrypt) like on the official website

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

On 2019-06-28 12:02:30 -0500, Derek Martin wrote: > On Fri, Jun 28, 2019 at 11:08:06AM +0200, Vincent Lefevre wrote: > > On 2019-06-26 14:36:01 -0500, Derek Martin wrote: > > > On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote: > > > > On 2019-06-25 14:2

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

On 2019-06-26 14:36:01 -0500, Derek Martin wrote: > On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote: > > On 2019-06-25 14:26:16 -0500, Derek Martin wrote: > > > In some cases it might get cleaned up, but you can just have your > > > .profile (or whateve

Re: meaning of number of lines in the message (%l in index_format)

On 2019-06-26 10:22:04 +0200, Daan van Rossum wrote: > I also don't use %c for the same reason. Fixing the units to 'k' > would make me switch to %c instead of %l as well... Having an integer value with the KB unit would also be OK for me. I don't care much about accurate values for small

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

On 2019-06-25 14:26:16 -0500, Derek Martin wrote: > On Tue, Jun 25, 2019 at 09:11:22PM +0200, Vincent Lefevre wrote: > > On 2019-06-24 17:18:27 -0500, Derek Martin wrote: > > > Mutt honors $TMPDIR. You should set it. You should probably not use > > > /tmp, especi

Re: $TMPDIR (was Re: Security: Mutt and mailcap rules)

On 2019-06-24 17:18:27 -0500, Derek Martin wrote: > Mutt honors $TMPDIR. You should set it. You should probably not use > /tmp, especially on a multi-user system, especially if you care about > security (privacy to be more precise, but that's part of security). > You should probably also not put

  1   2   3   4   5   >