potentially incorrect conversion of pointer to unsigned long

[Vincent Lefevre]

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 **) p->data));
  break;
case DT_ADDR:
  if (!p->init && *((ADDRESS **) p->data))
  {
char tmp[HUGE_STRING];
*tmp = '\0';
rfc822_write_address (tmp, sizeof (tmp), *((ADDRESS **) p->data), 0);
p->init = (unsigned long) safe_strdup (tmp);
  }
  break;
case DT_RX:
{
  REGEXP *pp = (REGEXP *) p->data;
  if (!p->init && pp->pattern)
p->init = (unsigned long) safe_strdup (pp->pattern);
  break;
}
  }
}

where safe_strdup returns a char *. 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 smaller than pointers (e.g. with the LLP64 data model, like
under MS Windows64).

There is also the same kind of issue with the MuttVars initializer
in init.h.

Now, I think that if (uintptr_t) -1 <= (unsigned long) -1, the
Mutt code should be OK (I assume that the result of a conversion
between a pointer and an integer does not depend on the integer
type, but I know that not all people agree with me).

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). Otherwise check (uintptr_t) -1 <= (unsigned long) -1
in configure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 could lead to them being
> > > interpreted as command arguments.
> > 
> > Just to be clear, the ticket is actually advocating for sanitizing the
> > leading "-", into "_" as other unsafe characters are.  I further wonder
> > if we should just remove "-" from the whitelist rather than adding a
> > special case for it.
> > 
> > As always, any feedback or historical context is very welcome.
> 
> Please don't. Add a "./" prefix. That way the filename is unchanged in
> meaning.

I agree that the "./" prefix is the best solution, but only when
the filename starts with '-'.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Security: Mutt and mailcap rules

[Vincent Lefevre]

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:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908

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 (quoted));
needspipe = FALSE;
  }

But it appears that the filename is usually or always sanitized.
The code is not enough documented about that.

If the filename is expected to be always sanitized, this should
probably be double-checked here to be sure and potentially avoid
future security bugs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: potentially incorrect conversion of pointer to unsigned long

[Oswald Buddenhagen]

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). Otherwise check (uintptr_t) -1 <= (unsigned long) -1
> in configure.
> 
it's easier to just use !! or put != NULL at the end instead of the cast.

Re: Security: Mutt and mailcap rules

[Gero Treuner]

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 ''/var/tmp/_.txt''"
> 
> I've reported a general bug in Debian:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908

There is a related "bug" with similar conclusion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928037


As the plain %s looks insane (but isn't here because it's the caller
responsible for providing only safe filenames) and probably continues to
attract people to imprudently disimprove the situation, what about some
education?

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?

IMO then it pops up for the right audience of "interested" people
building systems ;-)


Kind regards,
   Gero

Re: Security: Mutt and mailcap rules

[Kevin J. McCarthy]

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 (quoted));
   needspipe = FALSE;
 }


It's sanitized externally by mutt_rfc1524_expand_filename() for 
receive-mode usage.  See mutt_view_attachment(), 
mutt_print_attachment(), and autoview_handler().


If the filename is expected to be always sanitized, this should 
probably be double-checked here to be sure and potentially avoid 
future security bugs.


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.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Security: Mutt and mailcap rules

[Kevin J. McCarthy]

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 
mode without a template.  I'll add a fix for that.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: potentially incorrect conversion of pointer to unsigned long

[Kevin J. McCarthy]

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 smaller than pointers (e.g. with the LLP64 data model, 
like under MS Windows64).


Thanks, Vincent.  It always seemed a bit dubious to me, but since it has 
been that way for 25 years, I figured "let it be".  :-)


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).


Okay, I will work on this.  I think it's better to fix this the right 
way now then get bitten by this later.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Security: Mutt and mailcap rules

[Vincent Lefevre]

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 automatically
fix these quoting issues.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: potentially incorrect conversion of pointer to unsigned long

[Vincent Lefevre]

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 require the use of C99 designators for the MuttVars
> > initialization). Otherwise check (uintptr_t) -1 <= (unsigned long) -1
> > in configure.
> > 
> it's easier to just use !! or put != NULL at the end instead of the cast.

AFAIK, the value itself matters, not just the fact that it is
non-zero.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 in the encoded message. For instance, 8bit and base64 can
give significantly different results (unfortunately some mail software
uses base64 even when 8bit would be sufficient, and this is what
happens with some GNU mailing-list, where the users' messages are
re-encoded in base64). Moreover, one does not have an indication on
what encodings are used.

I think that the manual should say more about these issues.
Perhaps discourage this sequence?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Kevin J. McCarthy]

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,

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Security: Mutt and mailcap rules

[Kevin J. McCarthy]

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 interestingly, it looks like the print command would fail in send 
mode without a template.  I'll add a fix for that.


I've pushed some commits to stable and master with bug fixes and code 
cleanup.


I removed the return value from mutt_rfc1524_expand_filename(), and the 
"special case" handling in send-mode from attach.c.  I think this, along

with the other commits, makes the code much clearer now.

Also, I made sure the filename parameter to 
mutt_rfc1524_expand_command() is run through either 
mutt_rfc1524_expand_filename() or through the sanitize command.  The 
test field was missing this, but I don't think in practice anyone has %s 
in a test field.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Security: Mutt and mailcap rules

[Cameron Simpson]

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 in Debian:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908


Just a tangent because we've been talking about sanitising filenames 
elsewhere...


Interestingly, a reading of mailcap(5) on Ubuntu and of RFC 1524 shows 
that it says _nothing_ about shell quoting.


All the text says that %s shall be replaced with a filename containing 
the body (or attachment). Now, clearly that needs to be Bourne shell 
safe, but the text of the RFC and the manual entry say nothing about how 
that is achieved.


My inference from reading them is that the supplied filename is itself 
shell safe without quotes - it would need to contain no shell 
punctuation or whitespace. And in that form, it wouldn't matter if the 
mailcap recipe contained quotes:


 less '%s'

works as:

 less 'foo.txt'

and a recipe without quotes:

 less %s

works as:

 less foo.txt

with such a filename.

Of course, _all_ the mailcap examples in both these documents are 
without quotes, suggesting that a tool can put in a shell quoted string 
safely as mutt endeavours to do, allow it to preserve a presupplied 
filename closely.


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 safe filename regardless of the source filename. One 
which would be safe in quotes or not.


Our obligation here is to pass the filename correctly to the recipe 
command. The preferred way is a shell-quoted string replacing %s because 
that lets us preserve any suggested/provided filename most accurately.  
But we _can_ notice a '%s' easily and provide a 
safe-if-quoted-or-unquoted filename, and I think therefore that we ought 
to.


[... mutt code specifics snipped ...]

But it appears that the filename is usually or always sanitized.
The code is not enough documented about that.

If the filename is expected to be always sanitized, this should
probably be double-checked here to be sure and potentially avoid
future security bugs.


I think we should try to be robust against '%s' in a mailcap recipe if 
we notice it, because we can provide an unquoted-and-more-sanitised 
filename in that circumstance which won't be misused but a recipe with 
erroneous extra quotes.


I'm happy to try to make some time to understand the mutt code and 
suggest a patch if there's agreement about this.


Cheers,
Cameron Simpson 

Re: potentially incorrect conversion of pointer to unsigned long

[Cameron Simpson]

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 union (I think
> that this would require the use of C99 designators for the MuttVars
> initialization). Otherwise check (uintptr_t) -1 <= (unsigned long) -1
> in configure.
>
it's easier to just use !! or put != NULL at the end instead of the cast.


AFAIK, the value itself matters, not just the fact that it is
non-zero.


If I were doing this in Python or any other object oriented language I'd 
have a special sentinel value of the right type i.e. _not_ some magic -1 
value we expect to not match any other pointer-as-integer value and also 
not NULL, but an actual distinct special purpose (char*).


So how about this:

   #define UNSET_CHAR_PTR ""

and to use UNSET_CHAR_PTR instead of (uintptr_t)-1 and (unsigned 
long)-1.


Specificly, this way we (a) avoid doing any casts and (b) avoid any need 
for a union and its associated cognitive dissonance and (c) avoid a 
magic number in the code (the -1, in whatever form).


I'm totally serious about this, BTW.

Cheers,
Cameron Simpson 

Re: potentially incorrect conversion of pointer to unsigned long

[Cameron Simpson]

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 UNSET_CHAR_PTR[] = "";

so that there'd be just once instead of it.

Otherwise the suggestion remains.

Cheers,
Cameron Simpson 

Re: Security: Mutt and mailcap rules

[Kevin J. McCarthy]

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 safe filename regardless of the source 
filename. One which would be safe in quotes or not.


I'm -1 on this.  The manual clearly says not to add quotes, 
.  While not impossible, 
the code would not be dead-simple either, e.g. a "poor man's 
nametemplate" entry like:

  text/crazy; foo 'bar'%s'mysuffix'

Furthermore, the filename sanitization takes place outside the function, 
before tmpdir generation and data copy or symlink occur.  Adding the 
described aggressive sanitization inside mutt_rfc1524_expand_command() 
would simply lead to the wrong filename being in the invocation.


This is also why the existing sanitization can't be put inside for %s. 
If $tmpdir is set to "~/déchets", none of the resulting $tmpdir files 
would be readable, because the whole path is passed in.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

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

[Vincent Lefevre]

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 commit
> a fix, or should I put this on my todo list?

See commit 6a74e24e57dd78a9de3d7676bd7c6d2f42228a8d.

Is this OK?

BTW, I've noticed that the style used in the manual is not consistent:
  * the letter case for the folder types (mbox, mmdf, maildir, mh);
  * the markup of the header fields and whether the ":" is present.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: potentially incorrect conversion of pointer to unsigned long

[Vincent Lefevre]

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 **) 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). Otherwise check (uintptr_t) -1 <= (unsigned long) -1
> > > > in configure.
> > > >
> > > it's easier to just use !! or put != NULL at the end instead of the cast.
> > 
> > AFAIK, the value itself matters, not just the fact that it is
> > non-zero.
> 
> If I were doing this in Python or any other object oriented language I'd
> have a special sentinel value of the right type i.e. _not_ some magic -1
> value we expect to not match any other pointer-as-integer value and also not
> NULL, but an actual distinct special purpose (char*).

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 uintptr_t, i.e.
when converting a uintptr_t to unsigned long, there is no loss of
information. This way of checking the size of the unsigned integer
types in term of values is completely portable (as opposed to sizeof,
which includes the possible padding bits / bytes).

> So how about this:
> 
>#define UNSET_CHAR_PTR ""
> 
> and to use UNSET_CHAR_PTR instead of (uintptr_t)-1 and (unsigned long)-1.

No, this is not the intended use of (uintptr_t) -1 and (unsigned long) -1
above.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Security: Mutt and mailcap rules

[Vincent Lefevre]

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

returns nothing.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Kevin J. McCarthy]

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, maildir, mh);
 * the markup of the header fields and whether the ":" is present.


By all means, feel completely free to tackle that if you would like to. 
:-)


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: potentially incorrect conversion of pointer to unsigned long

[Cameron Simpson]

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 uintptr_t, i.e.
when converting a uintptr_t to unsigned long, there is no loss of
information. This way of checking the size of the unsigned integer
types in term of values is completely portable (as opposed to sizeof,
which includes the possible padding bits / bytes).
No, this is not the intended use of (uintptr_t) -1 and (unsigned long) 
-1

above.


Sorry, I misunderstood.

Cheers,
Cameron Simpson 

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

[Kurt Hackenberg]

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 mostly doesn't work. Maybe mbox read counts 
lines anyway, so this was easy? And originally there was nothing but mbox?

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

[Patrick Shanahan]

* 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,
> >   and possibly IMAP folders)
> 
> Seems not very useful if it mostly doesn't work. Maybe mbox read counts
> lines anyway, so this was easy? And originally there was nothing but mbox?

maybe not for some but there are still pleny of mbox systems which do
benefit from "%l".  thankypu,

started with mbox many years ago and have found no impelling reason to
change.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Re: Security: Mutt and mailcap rules

[Kevin J. McCarthy]

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* working towards contributing.  I would 
be delighted if you want to poke around the code and suggest some 
patches.  Feel free, even, to prove me wrong about the quoting idea; 
perhaps there is something inbetween worth considering.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Security: Mutt and mailcap rules

[Cameron Simpson]

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 
ideas today for pushback against *you* working towards contributing.  
I would be delighted if you want to poke around the code and suggest 
some patches.  Feel free, even, to prove me wrong about the quoting 
idea; perhaps there is something inbetween worth considering.


Your point about $tmpdir being an arbitrary path which needs to work is 
telling, and I hadn't realised its implications. Needs thought.


Were it a simple filename it would all be easy. Maybe a chdir(tmpdir) 
before running the shell command with a simple filename?


Anyway, I'll think about ways to make this kind of thing robust.

Cheers,
Cameron Simpson