Re: Security: Mutt and mailcap rules

On Sat, Jun 22, 2019 at 12:24:16PM +0200, Vincent Lefevre wrote: After reading the code, it appears that OPTMAILCAPSANITIZE is not used for %s: else if (*cptr == 's' && filename != NULL) { mutt_buffer_quote_filename (quoted, filename); mutt_buffer_addstr (buf, mutt_b2s

Re: potentially incorrect conversion of pointer to unsigned long

On 2019-06-22 12:40:39 +0200, Oswald Buddenhagen wrote: > On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: > > p->init = (unsigned long) safe_strdup (* ((char **) p->data)); > > > > IMHO, the best solution for safety would be to use a union (I think > > that this would

Re: Security: Mutt and mailcap rules

On 2019-06-22 13:40:36 +0200, Gero Treuner wrote: > I don't want the executable to be bloated, but what do you think about a > script checking mailcap at build time regarding this issue? In Debian, /etc/mailcap is updated by the update-mime script. The check could be done there. And it could also

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

The manual says: %l number of lines in the message (does not work with maildir, mh, and possibly IMAP folders) I think that it should emphasize on the fact that this is the number of lines

Re: Security: Mutt and mailcap rules

Hi, On Sat, Jun 22, 2019 at 12:24:16PM +0200, Vincent Lefevre wrote: > FYI, due to incorrect mailcap rules, which use '%s' or similar > instead of just %s, the filename quoting system in Mutt eventually > makes the filename *unquoted*, i.e. reversing its purpose, e.g. > > "less

Security: Mutt and mailcap rules

FYI, due to incorrect mailcap rules, which use '%s' or similar instead of just %s, the filename quoting system in Mutt eventually makes the filename *unquoted*, i.e. reversing its purpose, e.g. "less ''/var/tmp/_.txt''" I've reported a general bug in Debian:

Re: potentially incorrect conversion of pointer to unsigned long

On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: > p->init = (unsigned long) safe_strdup (* ((char **) p->data)); > > IMHO, the best solution for safety would be to use a union (I think > that this would require the use of C99 designators for the MuttVars > initialization).

Re: Security: Mutt and mailcap rules

On Sat, Jun 22, 2019 at 06:49:03AM -0700, Kevin J. McCarthy wrote: No, the setup code is complicated, as you can see from the above listed functions. Send mode directly uses the filename if a nametemplate isn't required. And interestingly, it looks like the print command would fail in send

Re: potentially incorrect conversion of pointer to unsigned long

On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: Thus one has conversions of a pointer (char *) to unsigned long. This is implementation-defined and can even be undefined behavior if "the result cannot be represented in the integer type", in particular if unsigned long is

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

On Sat, Jun 22, 2019 at 10:47:42PM +0200, Vincent Lefevre wrote: I think that the manual should say more about these issues. Perhaps discourage this sequence? I agree it would be good to mention these details. Would you like to commit a fix, or should I put this on my todo list? Thank you,

Re: potentially incorrect conversion of pointer to unsigned long

On 23Jun2019 09:01, Cameron Simpson wrote: So how about this: #define UNSET_CHAR_PTR "" and to use UNSET_CHAR_PTR instead of (uintptr_t)-1 and (unsigned long)-1. Actually a macro wouldn't do, particularly if the macro gets used in another file. You'd need a static string. char

Re: Security: Mutt and mailcap rules

On Sun, Jun 23, 2019 at 08:55:38AM +1000, Cameron Simpson wrote: I'm happy to try to make some time to understand the mutt code and suggest a patch if there's agreement about this. By the way, please don't mistake our initial pushback against your ideas today for pushback against *you*

Re: Security: Mutt and mailcap rules

On 22Jun2019 12:24, vincent lefevre wrote: FYI, due to incorrect mailcap rules, which use '%s' or similar instead of just %s, the filename quoting system in Mutt eventually makes the filename *unquoted*, i.e. reversing its purpose, e.g. "less ''/var/tmp/_.txt''" I've reported a general bug

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

On 2019-06-22 16:47, Vincent Lefevre wrote: The manual says: %l number of lines in the message (does not work with maildir, mh, and possibly IMAP folders) Seems not very useful if it

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

* Kurt Hackenberg [06-22-19 21:54]: > On 2019-06-22 16:47, Vincent Lefevre wrote: > > > The manual says: > > > > %l number of lines in the message > > (does not work with maildir, mh, > >

Re: Security: Mutt and mailcap rules

On 2019-06-22 15:12:37 -0700, Kevin J. McCarthy wrote: > The test field was missing this, but I don't think in practice > anyone has %s in a test field. At least under Debian, with the 562 lines of /etc/mailcap on my machine, perl -ne '/(test *=[^;]*%s[^;\n]*)/ and print "$1\n"' /etc/mailcap

Re: Security: Mutt and mailcap rules

On Sun, Jun 23, 2019 at 08:55:38AM +1000, Cameron Simpson wrote: Returning to the quotes-in-mailcap-recipes issue, I'd be all for mutt noticing _and warning_ about mailcap entries with '%s' in them, and maybe doing an aggressive filename sanitisation at that point to provide an _unquoted_ but

Re: potentially incorrect conversion of pointer to unsigned long

On 23Jun2019 02:28, vincent lefevre wrote: I don't understand what you mean. -1 is *not* some magic value. When -1 is converted to the unsigned integer type, it yields the maximum value of the type. Thus (uintptr_t) -1 <= (unsigned long) -1 is true iff unsigned long is at least as large as

Re: potentially incorrect conversion of pointer to unsigned long

On 22Jun2019 21:14, vincent lefevre wrote: On 2019-06-22 12:40:39 +0200, Oswald Buddenhagen wrote: On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: > p->init = (unsigned long) safe_strdup (* ((char **) p->data)); > > IMHO, the best solution for safety would be to use a

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

On Sun, Jun 23, 2019 at 02:17:37AM +0200, Vincent Lefevre wrote: See commit 6a74e24e57dd78a9de3d7676bd7c6d2f42228a8d. Is this OK? Yes, that looks great. Thank you. BTW, I've noticed that the style used in the manual is not consistent: * the letter case for the folder types (mbox, mmdf,

Re: Security: Mutt and mailcap rules

On Sat, Jun 22, 2019 at 07:05:58AM -0700, Kevin J. McCarthy wrote: On Sat, Jun 22, 2019 at 06:49:03AM -0700, Kevin J. McCarthy wrote: No, the setup code is complicated, as you can see from the above listed functions. Send mode directly uses the filename if a nametemplate isn't required. And

Re: Security: Mutt and mailcap rules

On 22Jun2019 20:29, Kevin J. McCarthy wrote: On Sun, Jun 23, 2019 at 08:55:38AM +1000, Cameron Simpson wrote: I'm happy to try to make some time to understand the mutt code and suggest a patch if there's agreement about this. By the way, please don't mistake our initial pushback against your

Re: potentially incorrect conversion of pointer to unsigned long

On 2019-06-23 09:01:43 +1000, Cameron Simpson wrote: > On 22Jun2019 21:14, vincent lefevre wrote: > > On 2019-06-22 12:40:39 +0200, Oswald Buddenhagen wrote: > > > On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: > > > > p->init = (unsigned long) safe_strdup (* ((char **)

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

On 2019-06-22 14:15:25 -0700, Kevin J. McCarthy wrote: > On Sat, Jun 22, 2019 at 10:47:42PM +0200, Vincent Lefevre wrote: > > I think that the manual should say more about these issues. Perhaps > > discourage this sequence? > > I agree it would be good to mention these details. Would you like to

potentially incorrect conversion of pointer to unsigned long

I've noticed after the latest changes (but the issue is older), in init.c: static void mutt_set_default (struct option_t *p) { switch (p->type & DT_MASK) { case DT_STR: case DT_PATH: if (!p->init && *((char **) p->data)) p->init = (unsigned long) safe_strdup (* ((char

Re: Ticket 151 - strip leading '-' for mailcap sanitize

On 2019-06-22 08:38:37 +1000, Cameron Simpson wrote: > On 21Jun2019 12:20, Kevin J. McCarthy wrote: > > On Fri, Jun 21, 2019 at 12:09:19PM -0700, Kevin J. McCarthy wrote: > > > noticed that a leading > > > '-' is not stripped from filenames, which