Re: Compatibility with mailx aliases

[Alejandro Colomar]

Hi Walter,

On Sat, Jun 22, 2024 at 10:36:52AM GMT, Rene Kita wrote:
> On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > aliases:
> > 
> >   alias john"John Dou "

How about addresses that themselves contain quotes, such as
"John R. Doe" ?

A lot of existing software requires quoting the name when it contains
'.'.  What does BSD or GNU mailutils with those?  Does it use single
quotes or what?  Such as

'"John R. Doe" '

?

Have a lovely day!
Alex

> > 
> > With full addresses, since they contain spaces, you need to enclose them
> > in quotes.  Any unix user would tend to add those quotes since there are
> > three fields there, not five.
> > 
> > If you add those quotes in a mutt aliases file, mutt doesn't recognize
> > that alias.  This is an inconsistency.  And an inconvenience, since it
> > forces you to use two aliases files, one for mail(1) and another one for
> > mutt.
> > 
> > It would be logical to add mutt compatibility for this case and even
> > more convenient if mutt added those quotes when generating aliases.
> 
> Sounds reasonable. Allowing to read quoted aliases seems pretty straight
> forward, see the patch below. Of course we might break some ones
> existing aliases, so this might be better enabled via a new option.
> 
> If it is a new option, should this also determine how we write it? Then
> the option should probably make one style mandatory. I'm not sure if
> this is worth the trouble.
> 
> ---
> diff --git a/init.c b/init.c
> index c84815c2..a398ec90 100644
> --- a/init.c
> +++ b/init.c
> @@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
> pointer_long_t udata, BUFF
>mutt_set_current_menu_redraw_full ();
>}
>  
> -  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
> MUTT_TOKEN_SEMICOLON);
> +  mutt_extract_token (buf, s, MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
>dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
> buf->data));
>  

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Mon, May 13, 2024 at 10:10:50AM GMT, Derek Martin wrote:
> On Fri, May 10, 2024 at 02:16:12AM +0200, Eike Rathke wrote:
> > If you can't trust but need to, then verify. The fingerprint over
> > a trusted channel. This has been part of PGP since the beginning.
> 
> Indeed, but that's what I've been saying.  The use of autocrypt (or
> similar features) downplays the need for this, and encourages naive
> users to skip this important step.

Just to clarify, the feature I'm proposing was designed by autocrypt
people (in parallel to me), but is orthogonal to it.  It's not related
at all, and doesn't encourage skipping this important step.  I'm myself
not an autocrypt user, and agree with you on that.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: [PATCH v1] Don't introduce spurious blank lines in protected blocks

[Alejandro Colomar]

Hi наб,

On Sat, May 11, 2024 at 05:18:17PM GMT, наб wrote:
> With the parts that remove leading newlines ‒
> 
> On Sat, May 11, 2024 at 01:27:09PM +0200, Alejandro Colomar wrote:
> > @@ -1196,7 +1196,7 @@ int mutt_signed_handler (BODY *a, STATE *s)
> >rc = mutt_body_handler (a, s);
> >  
> >if (s->flags & MUTT_DISPLAY && sigcnt)
> > -state_attach_puts (_("\n[-- End of signed data --]\n"), s);
> > +state_attach_puts (_("[-- End of signed data --]\n"), s);
> >  
> >return rc;
> >  }
> >  if (s->flags & MUTT_DISPLAY)
> > -{
> > -  state_puts ("\n", s);
> >state_attach_puts (_("[-- End of PGP/MIME encrypted data --]\n"), s);
> > -}
> >  
> >  mutt_free_body ();
> >  /* clear 'Invoking...' message, since there's no error */
> > diff --git a/smime.c b/smime.c
> > index 4666cfe3d..e0e7ef4bf 100644
> > --- a/smime.c
> > +++ b/smime.c
> > @@ -2048,9 +2048,9 @@ static BODY *smime_handle_entity (BODY *m, STATE *s, 
> > FILE *outFile)
> >if (s->flags & MUTT_DISPLAY)
> >{
> >  if (type & ENCRYPT)
> > -  state_attach_puts (_("\n[-- End of S/MIME encrypted data. --]\n"), 
> > s);
> > +  state_attach_puts (_("[-- End of S/MIME encrypted data. --]\n"), s);
> >  else
> > -  state_attach_puts (_("\n[-- End of S/MIME signed data. --]\n"), s);
> > +  state_attach_puts (_("[-- End of S/MIME signed data. --]\n"), s);
> >}
> 
> ‒ I'm naturally worried about non-text signed input of, say
> "data\ndata\ndata" being rendered as
>   [-- Start of S/MIME signed data. --]
>   data
>   data
>   data[-- End of S/MIME signed data. --]
> which is not what the sender wrote, even more-so than pre-patch.
> 
> If this is somehow protected against (and if it's rendered as expected as
>   [-- Start of S/MIME signed data. --]
>   data
>   data
>   data
>   [-- End of S/MIME signed data. --]
> ) then this looks good to me.

Hmm, I didn't think of a way to beat that back then, but now I found it.
Meh.  Please ignore this patch.

Thanks for voicing your concerns, наб!

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

[PATCH v1] enter.c: Use wmem*() functions with wide-character strings

[Alejandro Colomar]

This avoids an explicit size multiplication, which can overflow the
calculation.

Signed-off-by: Alejandro Colomar 
Cherry-picked-from: neomutt.git 7df621a105e2 ("Use wmem*() functions with 
wide-character strings")
Link: <https://github.com/neomutt/neomutt/pull/4296>
[alx: Adapted diff and message to mutt(1)]
Signed-off-by: Alejandro Colomar 
---

Hi Kevin,

This is a patch from neomutt(1), which doesn't fix any particular bug,
but prevents plausible ones.  At the same time, it simplifies code.  I'm
sending it to you in case you're interested in it.

Have a lovely day!
Alex


Range-diff against v0:
-:  - > 1:  c54d1d2d3 enter.c: Use wmem*() functions with 
wide-character strings

 enter.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/enter.c b/enter.c
index 693f3b1dc..b4e1716cd 100644
--- a/enter.c
+++ b/enter.c
@@ -29,6 +29,7 @@
 #include "buffy.h"
 
 #include 
+#include 
 
 /* redraw flags for mutt_enter_string() */
 enum
@@ -175,7 +176,7 @@ static void replace_part (ENTER_STATE *state, size_t from, 
char *buf)
   if (savelen)
   {
 savebuf = safe_calloc (savelen, sizeof (wchar_t));
-memcpy (savebuf, state->wbuf + state->curpos, savelen * sizeof (wchar_t));
+wmemcpy (savebuf, state->wbuf + state->curpos, savelen);
   }
 
   /* Convert to wide characters */
@@ -191,7 +192,7 @@ static void replace_part (ENTER_STATE *state, size_t from, 
char *buf)
 }
 
 /* Restore suffix */
-memcpy (state->wbuf + state->curpos, savebuf, savelen * sizeof (wchar_t));
+wmemcpy (state->wbuf + state->curpos, savebuf, savelen);
 FREE ();
   }
 
@@ -392,7 +393,7 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
  --i;
if (i)
  --i;
-   memmove (state->wbuf + i, state->wbuf + state->curpos, 
(state->lastchar - state->curpos) * sizeof (wchar_t));
+   wmemmove (state->wbuf + i, state->wbuf + state->curpos, 
state->lastchar - state->curpos);
state->lastchar -= state->curpos - i;
state->curpos = i;
  }
@@ -499,7 +500,7 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
  ++i;
while (i < state->lastchar && COMB_CHAR (state->wbuf[i]))
  ++i;
-   memmove (state->wbuf + state->curpos, state->wbuf + i, 
(state->lastchar - i) * sizeof (wchar_t));
+   wmemmove (state->wbuf + state->curpos, state->wbuf + i, 
state->lastchar - i);
state->lastchar -= i - state->curpos;
  }
  break;
@@ -521,8 +522,8 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
  else
--i;
}
-   memmove (state->wbuf + i, state->wbuf + state->curpos,
-(state->lastchar - state->curpos) * sizeof (wchar_t));
+   wmemmove (state->wbuf + i, state->wbuf + state->curpos,
+ state->lastchar - state->curpos);
state->lastchar += i - state->curpos;
state->curpos = i;
  }
@@ -553,8 +554,8 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
}
  }
 
- memmove (state->wbuf + state->curpos, state->wbuf + i,
-  (state->lastchar - i) * sizeof (wchar_t));
+ wmemmove (state->wbuf + state->curpos, state->wbuf + i,
+   state->lastchar - i);
  state->lastchar += state->curpos - i;
  break;
 
@@ -580,7 +581,7 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
  ;
my_wcstombs (buf, buflen, state->wbuf + i, state->curpos - i);
if (tempbuf && templen == state->lastchar - i &&
-   !memcmp (tempbuf, state->wbuf + i, (state->lastchar - i) * 
sizeof (wchar_t)))
+   !wmemcmp (tempbuf, state->wbuf + i, state->lastchar - i))
{
  mutt_select_file (buf, buflen, 0);
  if (*buf)
@@ -593,7 +594,7 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
  templen = state->lastchar - i;
  safe_realloc (, templen * sizeof (wchar_t));
   if (tempbuf)
-memcpy (tempbuf, state->wbuf + i, templen * sizeof (wchar_t));
+wmemcpy (tempbuf, state->wbuf + i, templen);
}
else
  BEEP ();
@@ -722,7 +723,7 @@ int _mutt_enter_string (char *buf, size_t buflen, int col,
/* see if the path has changed from the last time */
if ((!tempbuf && !state->lastchar) ||
 (tempbuf && templen == state->lastchar &&
- !memcmp (tempbuf, state->wbuf, state->lastchar * sizeof 
(wchar_t
+   

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 25, 2024 at 07:03:48PM -0400, Derek Martin wrote:
> On Thu, Apr 25, 2024 at 11:07:30PM +0200, Alejandro Colomar wrote:
> > While I don't have proof that no clients have major breakage with these
> > header fields, I can say that the most important ones don't have major
> > breakage.
> 
> Who are you to decide what the most important clients are?  If my
> favorite mail client is impacted, then that's the most important
> client of all... TO ME.

The most prevalent, I should've said.  Sorry for the imprecise wording.

> > mutt(1) has been protecting many header fields for several years already
> > (not by default, but you could enable it), and nobody has ever reported
> > a bug, did any?  The night sky is still up there and didn't fall on our
> > heads.
> 
> Virtually no one uses this feature,

That you didn't know of this feature doesn't mean "virtually nobody uses
it".  Did you do any survey?  I used it since the very first month I
started using mutt(1).

thunderbird(1) also protects the Subject using this mechanism.

And most people with whom I exchange signed/encrypted mail do use this
feature (maybe because I co-maintain the shadow project, and we are a
niche group that have to handle mail discussing security vulnerabilities
under embargo, and we don't want to disclose the slightest clue of such
a bug; but we do use those features).

Yeah, most people don't even use PGP, but going from that to virtually
no one is a big stretch.

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 25, 2024 at 03:02:14PM -0400, Derek Martin wrote:
> Absence of evidence fallacy.  For this to be a non-concern (logically
> speaking) you would need to prove that NO client has this problem.
> Proving a negative is not always impossible, but given the number of
> clients in existence, it's pretty impractical.
> 
> Now, how that leaves you IS NOT with conclusive proof that you should
> not do it this way... but rather a strong suggestion that IF you can
> find a good alternative that doesn't have the same potential weakness
> (nor other worse tradeoffs), choose that instead.

While I don't have proof that no clients have major breakage with these
header fields, I can say that the most important ones don't have major
breakage.

mutt(1) has been protecting many header fields for several years already
(not by default, but you could enable it), and nobody has ever reported
a bug, did any?  The night sky is still up there and didn't fall on our
heads.

I guess mutt(1) users interact with every other major provider regularly
even if in small numbers.

> But I'm repeating myself now.
> 
> > ok i have reread 2045 and it says [...]
> 
> Largely irrelevant, because of what it does NOT say...  For instance,
> it does not describe what the behavior should be if standard RFC 822
> headers appear BOTH in a mime header block AND in the actual message
> headers.  This is what's known as undefined behavior.  Therein lies
> the path to non-interoperability--which Mutt intends (or, at least has
> historically intended) to avoid.  I've already described how such a
> problem might arise in a previous message.  Avoid forseeable
> interoperability problems when possible.
> 
> Also, what the RFC does explicitly state is that headers in the MIME
> header block that do not begin with "content-" "CAN HAVE NO MEANING"
> [emph. mine], and "may be ignored."

That's a bit contradictory to another section of the same RFC:



Any sort of field may be present in the header of an entity, but
only those fields whose names begin with "content-" actually
have any MIME-related meaning.  Note that this does NOT imply
thay they have no meaning at all -- an entity that is also a
message has non-MIME header fields whose meanings are defined by
RFC 822.

Which clearly says they do have meaning; it's just that they don't have
MIME-related meaning.  Bascially I read that as saying that you can put
mostly whatever you want, and MIME won't care about it; it will have the
meaning that you or a different RFC want to assign to it.

>  It gives no indication that there
> would be an exception to those conditions for headers that are
> explicitly defined by RFC 822 (or its successors).  Therefore any
> processing of them that you do is at best ambiguous, i.e. again,
> undefined behavior, and at worst violates the spec (because processing
> them gives them meaning that the spec says they can not have).
> 
> Which of course isn't to say that the standard can't be extended or
> modified; but if you want to do that, then you should actually draft
> the standard extension and get it approved, well before asking clients
> whose central tenets include complying with standards (as Mutt's do)
> to implement such extensions.  The reasons to do that are to establish
> whether the relevant community even values the extension, and whether
> better alternatives may exist or be found.

I think RFC 2045/2.4 specifically allows that as an extension.  And the
draft that has been mentioned here is the document for documenting the
extension.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Steffen,

On Sun, Apr 21, 2024 at 01:01:54AM +0200, Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
>  <20240420191646.ZD-tN3eo@steffen%sdaoden.eu>:
>  |Kurt Hackenberg wrote in
>  | :
>  ||I would like to hold off on this until the draft becomes an RFC, if \
>  ||it does.
>  | --End of 
> 
> But i thing we refer to different drafts now.  I think you are all
> talking about draft-autocrypt-lamps-protected-headers-02, whereas
> i was at draft-ietf-lamps-header-protection-20.txt, and i find
> that terribly and needlessly excessive.  Note it also talks about
> a future deprecation of any non-protected messages, which i find
> too anticipatory, and needlessly so, too.
> 
>   #?0|kent:rfc$ wc -l draft-autocrypt-lamps-protected-headers-02.txt
>   3864 draft-autocrypt-lamps-protected-headers-02.txt
>   #?0|kent:rfc$ wc -l draft-ietf-lamps-header-protection-20.txt
>   11200 draft-ietf-lamps-header-protection-20.txt

I thoroughly checked the autocypt one at the start of this discussion,
IIRC.  Then someone pointed to the ietf one, and after some simple
inspection and web search, I think it's the evolution of the other, so
my assumption was that the autocrypt one will never be standard.

But yes, I prefer the simpler autocrypt one.

> I mean, basically, isn't that just "duplicate the most important
> headers of RFC 5322 into the signed part", aka "move practically
> anything useful out of the main header, and place it within the
> encrypted first multipart" (aka as via S/MIME and the Melnikov
> draft) for generation, and "if you understand cryptographic
> signatures and decrypting, use any such headers as the main
> instances, and best if you somehow make that warp visible".
> Which makes up six lines in this email.
> The latter draft i find an overly complicated thing.
> Btw i find that in general the ~1.4 decades brought lots of overly
> messy complicated stuff in the email architecture (a bit like
> DNS), and i find over and over again that we can be very lucky
> that the old and good ones generated protocols which scale from
> a dozen boxes to a billion ones, which all these, let me make it
> plain, crappy new things will *never* deliver, i bet.

And as you, I don't like autocrypt either.  I get my keys by human
interaction, and have .gnupg tracked by git(1) for any modification.
But in this matter, I think this autocrypt draft was sane.

> A nice Sunday everybody, if you can.

Have a lovely Sunday!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Werner,

On Sat, Apr 20, 2024 at 02:10:28PM +0200, Werner Koch wrote:
> Hi,
> 
> I only had a brief look into this thread but stumbled upon this:
> 
> > *7:   BCCs should be hidden recipients.
> 
> [BCCs shold be separate mails of course.]
> 
> Using a hidden recipient is a major hassle for everyone with more than a
> single key and in particular when several smartcards.  As a BCC
> recipient you would be forced to do trial decryption and swap smartcards
> over and over.  This is the very reason why I once introduced the
> --skip-hidden-recipients optin and franly I use it for years now and
> disable it only when needed.

Thanks for the feedback!  That would be my favourite approach as a user,
although as a programmer I wanted to avoid it, since it would need big
work.

Richard, I guess we should first change neomutt(1) to send separate
mails for BCC in non-encrypted mode, which will already be a pain, and
then probably the encrypted thing will follow.  AFAIK, it's sending a
single mail, isn't it?  That would already be an improvement, because at
the moment, since it sends a single message, I see no Bcc: field when
receiving a Bcc message, which makes me wonder why I receive them.
Having a separate mail in which the Bcc field is set would be a nicer
UX.

I'll put this thing at the end of the queue of things I want to do.  In
the meantime, users will have to live with the fact that BCC encrypted
mail leaks the BCCs.  :-)

> Salam-Shalom,

Have a lovely day!
Alex

>Werner
> 
> -- 
> The pioneers of a warless world are the youth that
> refuse military service. - A. Einstein

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kevin,

On Sat, Apr 20, 2024 at 11:39:17AM +0800, Kevin J. McCarthy wrote:
> 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.

Fair enough.

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

And fair enough.  Thank you for your time!

> If others really want the project to continue, it would be good for
> someone(s) to start picking up the reins.

If anyone does, I'll come back when this is an official RFC (maybe later
this year) to send patches.  :-)

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 04:56:30PM -0400, Derek Martin wrote:
> You're missing the point:  All software has bugs.  This would be a
> bug, but it's forseeable that mailers would have this bug.  For
> example, if the header parser you implement differentiates where to
> put the headers it's parsed based on what the header is--i.e. standard
> header vs. mime header, it may add the header to the wrong object, and
> now you have two subjects, two from headers, etc...  They are both
> headers, valid headers, that should be treated as headers--it just got
> the context wrong based on the name.
>
> In most cases this bug would be completely innocuous--and perhaps even
> beneficial (e.g. because it simplified the parser)--because mime
> header blocks typically should not have RFC 822 headers in them.
> Except now you've added a reason why they might.  Depending on what
> the borked client does next, this could inject further broken e-mail
> into the thread causing problems for everyone on it.
> 
> Does this bug exist anywhere?  Does any similar bug exist anywhere?  I
> don't know, but it's forseeable that such bugs may exist.

Actually, I've seen this bug.  My mail server (migadu) inserted a header
field right after the From field.  Since mutt(1) (and neomutt(1) with my
patches) insert a From in the protected MIME part, migadu also a field
after that From, invalidating my signature.

They fixed the bug in a few minutes after my report.

All software has bugs, but that doesn't mean not to use software, nor
not improve them.  Just fix the bugs.

>  Should you
> always avoid implementing functionality that might interact with a
> bug?  No... but if you can find a better design that is far less
> likely to interact with bugs, you should probably use that instead.

Having the signature in a header means redesigning the whole crypto in
emails.  That's likely going to trigger many bugs too.  I see your point
but I'm not sure the alternative is definitely better.

> > already a decent time frame that other projects can do the same thing.
> > Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
> > all use this mechanism.  So we can say it's de-facto standard, even if
> > it's not yet standard.
> 
> I don't think you can... I've never heard of Memory Hole, nor until
> this conversation had I heard of autocrypt.

$ MANWIDTH=72 man neomuttrc | grep -A22 crypt_protected_headers_read$
 crypt_protected_headers_read
Type: boolean
Default: yes

When  set,  NeoMutt will display protected headers ("Memory
Hole") in the pager, When set, NeoMutt  will  display  pro‐
tected  headers in the pager, and will update the index and
header cache with revised headers.

Protected headers are stored inside the encrypted or signed
part of an an email, to prevent  disclosure  or  tampering.
For  more information see https://github.com/autocrypt/pro‐
tected-headers Currently NeoMutt only supports the  Subject
header.

Encrypted messages using protected headers often substitute
the   exposed  Subject  header  with  a  dummy  value  (see
$crypt_protected_headers_subject).  NeoMutt will update its
concept of the correct subject after the message is opened,
i.e. via the  function.  If you reply to a
message before opening it, NeoMutt will end  up  using  the
dummy  Subject  header,  so  be sure to open such a message
first.  (Crypto only)

TBH, I don't know why it's called memory hole.  But it's what mutt(1)
uses.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 03:41:40PM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> > It's odd to me that, since OpenPGP and S/MIME both support MIME
> > encapsulation that the draft standard wouldn't use a separate MIME part
> > to handle the protected headers vs. stuffing it at the top of the
> > message body, which just seems kind of kludgy at best.
> 
> This also seems like a perfectly cromulent approach, and again better
> than the proposed one which puts nonstandard headers in a place where
> no standard says they can be. [Or perhaps the correct wording would
> be, "...which nonstandardly puts standard headers in a place where no
> standard says they should be."]

How would a program differentiate between a body whose contents are
header-field-like?  Header fields must go in a structured area.  MIME
was designed precisely for that purpose: allowing header fields in the
body of a message, by structuring the body to have other header areas.

The only viable alternative is the patatt(5) way: using the message
header, no need for MIME.  However, inertia seems to be using MIME.

> MIME header blocks are for MIME-specific metadata; even if no mail
> clients actually break due to this, it still feels gross.  Yes, the
> MIME spec says other fields can appear there and should be ignored (so
> long as they don't start with "content-") but having standard message
> headers in multiple places unexpectedly still runs the risk that
> insufficiently carefully implemented clients will get confused.

mutt(1) has been doing it since 2018.  That's not like 1970, but it's
already a decent time frame that other projects can do the same thing.
Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
all use this mechanism.  So we can say it's de-facto standard, even if
it's not yet standard.

Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Fri, Apr 19, 2024 at 03:17:17PM -0400, Derek Martin wrote:
> On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> > Signing header fields sounds reasonable, but I don't entirely like an
> > implementation that puts a copy of them in the message body, to be covered
> > by GPG.  I'd prefer something more direct, that signs headers without
> > copying them or modifying the message body.
> 
> This makes a lot of sense to me (assuming that this feature has
> genuine practical value, of which I remain largely unconvinced).  
> 
> First off:  Is there an actual RFC for the existing protected header
> scheme?

I don't think so.  It's being considered for a standard, though.  Will
posted a link in this thread:


>  If not, someone really ought to actually draft one and submit
> it, so that more people than just a handful of interested users of
> a small selection of specific mailer software could provide comments
> on the Request For Comments...
> 
> Secondly, there is a standard mechanism for adding non-standard
> headers to e-mail:  use the string "X-" before the thing, and add it
> to the normal message headers.

Not standard anymore.  Talking of RFCs...  See
.  The title of which is:

   Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols


> To the extent that this feature is
> useful, it would be just as useful for non-encrypted messages as for
> encrypted messages.  You could do something like this:
> 
> X-protected-header-key:  0x1234567...  # probably unnecessary, but
> might be interesting for confirmation?
> X-protected-headers: (A base64-encoded string representing the precise
> and complete contents of the headers which were signed)
> X-protected-headers-signature:  (the actual signature of the data made
> by the specified key)
> 
> The user could verify the signature of the signed headers, so long as
> the key is available and trusted.  The mailer could display and/or
> visually confirm the signed headers against the standard ones,
> ignoring white-space differences, etc..
> 
> This is not very well fleshed out, but it already strikes me as better
> than what Mutt currently does: 
> 
>   - it does not require even having MIME parts in such a message.



I think these days MIME is not so frowned upon as it once was.  But you
have a point.  patatt(5) actually implements an idea like yours for
signing patches including header fields, precisely for avoiding MIME.

>   - I don't love what Mutt is currently doing--it seems it has the
> potential to break existing clients which are not expecting
> message headers in the MIME header blocks.  A well-behaved client
> probably shouldn't break, but as we all know, not all software is
> well-behaved.  All mailers are expected to accept/ignore X-*
> headers.
>
> Also FYI, I removed the neo-mutt list from this post because I'm not a
> member and I don't cross-post; and also you probably don't need to
> include Werner separately, he's a longstanding member of this list. :)

Considering that this is a discussion for a patch set proposed to both
projects, I think cross-posting is fine, but okay.  I'll manually tell
later neomutt(1) developers about anything interesting.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Will,

On Fri, Apr 19, 2024 at 09:05:23AM -0700, Will Yardley wrote:
> I hadn't known about the protected header feature for S/MIME / OpenPGP
> before this thread came up (though as mentioned elsewhere in the thread,
> it seems like mainline mutt already supports it going back 4-5 years...
> just defaulting to off and limited to the Subject header).

And you're not the only one.  I know at least one programmer, who works
in security, and didn't know about $crypt_protected_headers_write until
he received a message from me that used it, a few years ago.

> Seems like it's based on this draft:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/
> 
> That said, IMO, adding (and especially enabling by default) support for
> draft RFCs that aren't yet standard / ratified has caused problems for
> mutt in the past (for example, the 'Mail-Followup-To' draft, which mutt,
> basically alone among MUAs, still supports, but which expired, and
> hasn't been updated since 1997)

As you said, mutt(1) already has partial support for it, from several
years ago.  (It supports the sending side; not the receiving one).

Some of my patch sets to neomutt(1) do:

-  Add support on the sending side (neomutt(1) didn't have this).
-  Add support on the receiving side.
-  Enable it by default.

If you prefer to wait for it to be standard, I'm fine with it.  The
draft says it expires in 2024-09, so I'll check around that date to see
if they have done a release, and come back with patches for mutt(1).

> There's probably a balance of some kind to be struck between being
> appropriately concerned about security / not completely dismissing
> potential concerns, or being too slow to embrace new standards, but also
> not jumping too enthusiastically into solving theoretical problems that
> have complicated solutions.

While implementing all of it could be complex, my idea would be to only
implement the most basic part of it:

-  Print the protected headers, just like mutt(1) already does with the
   protected "Subject".
-  Enable it by default.

I've written code for these, and they seem quite simple.

Then some other feature could be to compare the headers against the
exposed ones, and emit a warning line if there are headers that don't
match.  This could lead to false positives with mailing lists that are
destructive to the original message, so this needs more careful
discussion.  But just showing the headers would already be enough to be
able to detect attacks by visual inspection, so I would be happy enough
with that.

> While the examples outlined as possible
> problems seem maybe technically possible, to me, as described, they
> don't seem to equate to a very serious security problem,

Yeah, it's not like a backdoor in xz.  We're not in a hurry to fix it.
But that's not to say that it's not a security vulnerability.  It's just
not a RCE.

> and in most
> cases, probably can be handled via common sense.

I'm not sure that's true.

> 
> Compared to the example of Thunderbird mentioned, I would say that mutt
> has a relatively more technical user-base, and one that may prioritize
> truth over beauty, esp. when it comes to email headers; sticking headers
> into the message body, but hiding them and / or rendering them in a
> different place seems kind of counter to Mutt's overall ethos.

Well, then I understand you agree with my intention to unhide those
header fields that mutt(1) currently writes but doesn't render?

> It's odd to me that, since OpenPGP and S/MIME both support MIME
> encapsulation that the draft standard wouldn't use a separate MIME part
> to handle the protected headers vs. stuffing it at the top of the
> message body, which just seems kind of kludgy at best.

The protected headers are part of the header area of the MIME part.
They are not part of the body area.  Below is a message, which you can
find on mutt-dev@'s archives at
<https://marc.info/?l=mutt-dev=171352201829360=mbox>.  You'll see
that the protected header fields are in the header area of the first
MIME part.

From mutt-dev  Fri Apr 19 10:22:49 2024
From: Alejandro Colomar 
Date: Fri, 19 Apr 2024 10:22:49 +
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: 
X-MARC-Message: https://marc.info/?l=mutt-dev=171352201829360
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--VlyiQqPR0XvZgf2n"


--VlyiQqPR0XvZgf2n
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Apr 2024 12:22:49 +0200
From: Alejandro Colomar 
To: mutt-dev@mutt.org
Subject: Re: Message security; protected header fields

Hi Kevin,

On Fri, Apr 19, 2024

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kevin,

On Fri, Apr 19, 2024 at 11:43:20AM +0800, Kevin J. McCarthy wrote:
> 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.

BTW, was there any discussion about it when it was added?  It would be
interesting to link to it when adding the code to neomutt(1).

I've found the release notes, the UPDATING file, and the commit, so far:

-  
-  


Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kurt,

On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> On Thu, Apr 18, 2024 at 06:37:50PM +0200, Alejandro Colomar wrote:
> 
> > I reported around a month ago a couple of security vulnerabilities to
> > neomutt(1), but which are also present in mutt(1) and every MUA
> 
> So the main security vulnerability is that a recipient can tamper with
> header fields, and then reuse the message in some way, perhaps resend it?
> And you propose to cryptographically sign certain headers to detect
> tampering?

Yes.  And as Kevin pointed out, mutt(1) is already doing this.  It just
doesn't show it in the receiving side (I can't understand why).  So, at
least someone else thought in the past that it was a good idea too.

> Signing header fields sounds reasonable, but I don't entirely like an
> implementation that puts a copy of them in the message body, to be covered
> by GPG.  I'd prefer something more direct, that signs headers without
> copying them or modifying the message body.
> 
> DKIM already exists, and signs header fields.  It publishes a key through
> DNS, and so is used by the administrator of the sending domain rather than
> by the end user.  Is that acceptable?
> 
> Email authentication: <https://en.wikipedia.org/wiki/Email_authentication>
> 
> DKIM: <https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>

I don't trust too much anything not covered by GPG.  And, as said, we
don't need to patch mutt(1) to add this protection.  Only to use it in
the receiving side, which should be simple.

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Kevin,

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> 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.

I can write the code, if you have the time to review it.  I've already
written it for neomutt(1), so I'd only need to adapt it a little bit.

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

Ahh, sorry.  I assumed it was by accident because it didn't make sense
to me that you protect headers but then don't display them.  I was
wrong; I've found that you protect them on purpose in mutt_protect().

Which makes me wonder: if you considered it good to protect them, why
not display them, as with the protected subject?  Did you forget?  What
good is a protected header that is not shown, nor validated?  Yeah, one
would be able to inspect the raw message to check if it contains the
headers, but meh.

So, we wouldn't need to add much to mutt(1).  If you want me to send the
patches, just let me know.

Have a lvoely day!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote:
> On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote:
> > Protecting the recipients and the in-reply-to doesn't mean hiding it.
> > It means providing a copy inside the signed part, so that it can be
> > verified against tampering.  It's not about encrypting them.
> 
> You can already do this in mutt by using a script as your editor to
> parse the headers, add the info you want to the body, and then edit
> your message.  But it doesn't really guarantee what you want because
> as I already pointed out, the message headers may differ from the
> actual recipients for a variety of reasons (Bcc, forwarding, mailing
> lists, etc.).  It may indicate a difference--it does not guarantee
> that the difference is caused by tampering.  It most likely is not, so
> it will most likely mislead you.

Hmmm, thanks.  I'll take the mailing list case into account.  Bcc is not
in the protected fields that I implemented, for obvious reasons.  When
forwarding, you're creating a new message (like when replying), and it
gets a new signature; I don't think this issue applies.

> The message interception scenario is possible, but I think highly
> improbable, especially for the sort of people who are using Mutt and
> encryption--savvy users.  It requires the attacker have superuser
> access to the mail system somewhere between you and your genuine
> recipients, AND either be known to your recipients, or your recipients
> must have no idea who should be on the message.  The attacker needs to
> be able to prevent the delivery of the original, to have time to
> inject the bogus message.  And your recipients need to already have
> the attacker's public key and trust it, or be set up to automatically
> download and use untrusted public keys...  

Well, if you see that your friend already sent an encrypted message to
that key, that could help trust that key, at least temporarily.

It only needs a man in the middle, but if they target you, that's a
reasonable scenario, I think.

And if the message is not encrypted, but only signed, it's not even
necessary a man in the middle.  An attacker can search for messages of
yours in mailing lists (or talk to you to get a new one, so the date is
more recent), download them, edit the headers, and bounce.

> > BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> > the Subject.  That's precisely why I wanted some agreement on this
> > outside of just neomutt(1).
> 
> How so?

I used thunderbird(1) for some time in the past (until 2023).  When you
receive an encrypted message created by mutt(1) and read it in
thunderbird(1), you only see the "..." subject.  You don't see the
actual subject.  Or maybe it was the other way around, I don't remember
well.

> > > 2. Many of these violate existing standards, or at least have no
> > >standard.  Standards exist for a reason--if you don't follow them,
> > >other people who don't happen to use the exact same client as you
> > >won't be able to interoperate.
> > 
> > I don't think so.  Again, I don't think you've understood the points.
> 
> For instance, if you rely on the in-body headers when they differ from
> the message headers, the other recipients' response behavior will
> differ from yours, because that is not how e-mail works.  The
> standards dictate that e.g. the reply-to header--not some random text in
> the message body--is the address that e-mail clients should send
> replies to.  So yes, it violates the spec.

Well, we could just add the warnings, and continue using the outer
headers.  It will be up to the user to decide if the warning is valid or
not.  Thanks for pointing these issues; that's precisely why I wanted
more review.

Thanks!

> 
> > Have a lovely night!
> 
> You too!

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 11:59:29PM GMT, Alejandro Colomar wrote:
> Hi Derek,
> 
> On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
> >g. Protecting the recipients is problematic for potentially several
> >   reasons--it prevents people from interacting normally with
> >   threads and their recipients.  The SMTP envelope needs at least
> >   the recipient you're actually sending to in that specific SMTP
> >   session, and the MTA will add the recipient's address in a
> >   Received header, so hiding that at least is pointless.  But if
> >   Mutt added these features it would be the only client to do so
> >   (AFAIK) making it very difficult for anyone using any other
> >   client to deal with.  You couldn't simply "reply-all" to, well,
> >   reply to all...  And again, you can just send separate messages.
> >   And if you really don't want your recipients to know about each
> >   other, then you shouldn't be sending them the same message
> >   anyway!  Avoid any possibility of embarrassment or worse--send
> >   separate messages.
> 
> I don't think you've understood the issue at all.
> 
> Protecting the recipients and the in-reply-to doesn't mean hiding it.
> It means providing a copy inside the signed part, so that it can be
> verified against tampering.  It's not about encrypting them.
> 
> So, if I manage you to send me a message saying "Yeah, go ahead.", and
> I change the recipient and in-reply-to header fields, I could maybe
> convince someone that you said yes to a different thread.  Does that
> not look like a security problem to you?  Well, that's fine.
> 
> BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
> the Subject.  That's precisely why I wanted some agreement on this
> outside of just neomutt(1).
> 
> > 2. Many of these violate existing standards, or at least have no
> >standard.  Standards exist for a reason--if you don't follow them,
> >other people who don't happen to use the exact same client as you
> >won't be able to interoperate.
> 
> I don't think so.  Again, I don't think you've understood the points.

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.

I use

$ mutt -v | head -n1
Mutt 2.2.12+68 (841caf1c) (2023-10-25)

See the reply that I sent you in the list archives, which I sent with
mutt(1), and you'll find the protected headers
<https://marc.info/?l=mutt-dev=171347742508069=mbox>:

From mutt-dev  Thu Apr 18 21:59:29 2024
From: Alejandro Colomar 
Date: Thu, 18 Apr 2024 21:59:29 +
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: 
X-MARC-Message: https://marc.info/?l=mutt-dev=171347742508069
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--T/e8leAN/4bSvaex"


--T/e8leAN/4bSvaex
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Apr 2024 23:59:29 +0200
From: Alejandro Colomar 
To: mutt-dev@mutt.org, neomutt-de...@neomutt.org
Subject: Re: Message security; protected header fields

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several


However, I don't see that in your message, which means that either this
bug doesn't reproduce with your configuration, or you use a different
version of mutt(1).  Still, I find it interesting that mutt(1) messages
will be protected even if you don't patch mutt(1) --at least in some
cases--.  However, you won't be able to benefit from those protections,
since you don't use those headers at all.

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Alejandro Colomar]

Hi Derek,

On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
>g. Protecting the recipients is problematic for potentially several
>   reasons--it prevents people from interacting normally with
>   threads and their recipients.  The SMTP envelope needs at least
>   the recipient you're actually sending to in that specific SMTP
>   session, and the MTA will add the recipient's address in a
>   Received header, so hiding that at least is pointless.  But if
>   Mutt added these features it would be the only client to do so
>   (AFAIK) making it very difficult for anyone using any other
>   client to deal with.  You couldn't simply "reply-all" to, well,
>   reply to all...  And again, you can just send separate messages.
>   And if you really don't want your recipients to know about each
>   other, then you shouldn't be sending them the same message
>   anyway!  Avoid any possibility of embarrassment or worse--send
>   separate messages.

I don't think you've understood the issue at all.

Protecting the recipients and the in-reply-to doesn't mean hiding it.
It means providing a copy inside the signed part, so that it can be
verified against tampering.  It's not about encrypting them.

So, if I manage you to send me a message saying "Yeah, go ahead.", and
I change the recipient and in-reply-to header fields, I could maybe
convince someone that you said yes to a different thread.  Does that
not look like a security problem to you?  Well, that's fine.

BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding
the Subject.  That's precisely why I wanted some agreement on this
outside of just neomutt(1).

> 2. Many of these violate existing standards, or at least have no
>standard.  Standards exist for a reason--if you don't follow them,
>other people who don't happen to use the exact same client as you
>won't be able to interoperate.

I don't think so.  Again, I don't think you've understood the points.

> 3. Probably most importantly, Mutt is basically in maintenance mode,
>i.e. no new features.  So none of this is likely to get
>implemented, even if one of the developers happened to agree with
>you.

I was just suggesting.  If you don't like it, then it's fine.

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Message security; protected header fields

[Alejandro Colomar]

Hi mutt(1) and neomutt(1) developers!

I reported around a month ago a couple of security vulnerabilities to
neomutt(1), but which are also present in mutt(1) and every MUA
(probably, I didn't do an exhaustive research).

Vulnerability reports:

-  <https://github.com/neomutt/neomutt/issues/4223>
-  <https://github.com/neomutt/neomutt/issues/4226>

I also sent a report to Debian and Red Hat security teams to issue a
couple of CVEs.  I haven't received a response from the security teams,
but I guess they're busy at the moment with xz.

Richard and a few other neomutt(1) developers have helped me discuss
and polish these features.

We created a page to discuss the security of messages, and have an
overview of how to address these issues, and a few smaller ones.

-  <https://github.com/neomutt/neomutt/discussions/4251>

This PR addresses both security vulnerabilities:

-  <https://github.com/neomutt/neomutt/pull/4227>

There are other spin-offs of that discussion, including the following
issues and PRs:

-  <https://github.com/neomutt/neomutt/pull/4221>
   (this was a debugging feature that led me to this rabbit hole)

-  <https://github.com/neomutt/neomutt/issues/4242>
-  <https://github.com/neomutt/neomutt/pull/4243>
-  <https://github.com/neomutt/neomutt/pull/4247>

-  <https://github.com/neomutt/neomutt/issues/4234>

-  <https://github.com/neomutt/neomutt/issues/4237>

-  <https://github.com/neomutt/neomutt/pull/4249>

-  <https://github.com/neomutt/neomutt/pull/4256>
-  <https://github.com/neomutt/neomutt/pull/4248>

-  <https://github.com/neomutt/neomutt/pull/4255>

Although it's a draft, since I have written alternative patches in other
PRs.  All the details are in the discussion page.

You're all invited to discuss this thing before we merge the changes.
I'd love if mutt(1) would be interested in coordinating the patches,
since I'm myself a mutt(1) user.  I just started developing them for
neomutt(1) because it's more open to development.  If you are open to
(some of) these changes, I could adapt the patches for mutt(1) too.

Here's an overview of my initial idea, using ASCII art.  Please scroll
to the right of the screen to see it all.  I've removed some bits that
I've discarded.

Date: Sat, 30 Mar 2024 12:22:13 +0100
From: Alejandro Colomar*10
Reply-To: e...@example.com*10
To: a...@kernel.es
Cc: b...@example.com   *10
Subject: ...

[-- Begin encryption information --]  \
Recipient: RSA key, ID 1234123412341234   |
Recipient: RSA key, ID 5678567856785678   }-- Hide: 
$crypt_encryption_info = no
Recipient: RSA key, ID    *7  |
[-- End encryption information --]        /

[-- Begin signature information --]
Good signature from: Alejandro Colomar 
aka: Alejandro Colomar 
aka: Alejandro Colomar Andres 
created: Sat Mar 30 12:22:13 2024
[-- End signature information --]

[-- Warning: the header field 'Reply-To' has been tampered with --]  *11
[-- Warning: the header field 'Sender' has been tampered with --]
[-- Warning: the header field 'Mail-Followup-To' has been tampered with --]
[-- Warning: the header field 'X-Original-To has been tampered with --]
[-- Warning: the header field 'To' has been tampered with --]
[-- Warning: the header field 'In-Reply-To' has been tampered with --]

[-- The following data is PGP/MIME signed and encrypted --]   *3
From: Alejandro Colomar*8  \ \
Sender: f...@foo.com   | |
Reply-to: f...@foo.com }-|-{- Weed: 
weed && _protected_headers_weed = yes
Mail-Followup-To: f...@foo.com | |  \- 
Don't send: $crypt_protected_headers_write = no
X-Original-To: f...@foo.com| |
To: f...@foo.com   | |
Cc: b...@example.com   | }-- Hide: 
$crypt_protected_headers_read = no
Subject: Foo  | |
In-Reply-To: <...>*9  / |
  *4/
Body body
body body body
body
[-- End of PGP/MIME signed and encrypted data --] *3


*3:   No gratuituous blanks after the begining or before the ending
  [-- ... --] markers.

*4:   Blank line is part of this block. This one is meaningful, and
  should be printed if the header area is printed; even if the
  header area has 0 fields!

*6:   We should default to protecting these fields in outbound email.
  Not doing so is a security ri

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

[Alejandro Colomar]

Hi Darek,

On Wed, Nov 15, 2023 at 01:25:29PM -0500, Derek Martin wrote:
> On Wed, Nov 15, 2023 at 07:10:52PM +0100, Alejandro Colomar wrote:
> > On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote:
> > > Hi!
> > > 
> > > On Fri, 10 Nov 2023 01:41, Alejandro Colomar said:
> > > 
> > > > This is breaking behavior, so it needs some more justification than just
> > > > the above.
> > > 
> > > FWIW, I am using another patch for 2 years now to send unattended but
> > > signed mails.  The patch requires a new option to avoid the risk of
> > > regressions.  See
> > > 
> > >   
> > > https://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20220725/thread.html
> > > 
> > > and Kevin's follow-up.  Unfortunately I had not have the time to
> > > continue working on the patch to get this or something else upstream.
> > 
> > Hmm.  Interesting.  I think I prefer not adding an option.  It's
> > breaking behavior
> 
> So, acknowledging that this discussion is mostly academic since
> there seems not to be anyone to maintain/support new features...

Yes, it's still academic and useful, since I plan to patch neomutt(1) in
the same way (and neomutt(1) is still maintained).  Only problem with
neomutt(1) is it doesn't seem to be compatible with mutt(1), in that
`neomutt -H -` doesn't seem to work.  (I reported that as a bug to
neomutt(1), although it seems they removed the feature on purpose a few,
years ago, which seems confusing to me.)

And of course, knowing what mutt(1) users think of the feature, would be
interesting.

> 
> > but at least it keeps it simple: you enable crypto in
> > the config, you get crypto.
> 
> No it doesn't.  I use both encryption and unattended mail, and I don't
> use gpg-agent or equivalent, quite intentionally, as I want the choice
> to use encryption to be quite deliberate, requiring me to type my
> passphrase each time I do so. Your method completely breaks me.  No
> thanks.

You could use a different config for those unattended actions.  For
example, you could source ~/.config/mutt/crypto.muttrc from your
.muttrc, but use a different .muttrc that doesn't include crypto.muttrc
in those unattended operations (you could use `mutt -F unattended.muttrc`
for that).

If I were writing mutt(1) from scratch, I'd say that's the sanest way to
do this, instead of not enabling a feature in those cases.

> 
> Besides which, this is Mutt's longstanding development philosophy.  It
> violates principle of least surprise.  An option is required. [And
> this, from a guy who hates adding options...]

Yeah, similar conflict in my head.  :)

Cheers,
Alex

> 
> -- 
> Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
> -=-=-=-=-
> This message is posted from an invalid address.  Replying to it will result in
> undeliverable mail due to spam prevention.  Sorry for the inconvenience.
> 



-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

[Alejandro Colomar]

Hi Werner!

On Wed, Nov 15, 2023 at 04:13:14PM +0100, Werner Koch wrote:
> Hi!
> 
> On Fri, 10 Nov 2023 01:41, Alejandro Colomar said:
> 
> > This is breaking behavior, so it needs some more justification than just
> > the above.
> 
> FWIW, I am using another patch for 2 years now to send unattended but
> signed mails.  The patch requires a new option to avoid the risk of
> regressions.  See
> 
>   https://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20220725/thread.html
> 
> and Kevin's follow-up.  Unfortunately I had not have the time to
> continue working on the patch to get this or something else upstream.

Hmm.  Interesting.  I think I prefer not adding an option.  It's
breaking behavior, but at least it keeps it simple: you enable crypto in
the config, you get crypto.  It keeps mutt(1) being interactive as
necessary: it will ask for the password as necessary, then do everything
else.  It is the user's responsibility to either not enable crypto in
the config, or do something to keep the keyring unlocked.

Your patch also serves me as an indicator that this patch touches the
right place in the code base.

I wonder if Kevin will accept patches with new features...

Thanks!
Alex

> 
> 
> Shalom-Salam,
> 
>Werner
> 
> -- 
> The pioneers of a warless world are the youth that
> refuse military service. - A. Einstein



-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Re: [PATCH] send.c: Allow crypto operations in batch and mailx modes.

[Alejandro Colomar]

On Fri, Nov 10, 2023 at 01:41:41AM +0100, Alejandro Colomar wrote:
> This is useful for signing patches with git-send-email(1).  Here's a
> working configuration for that:
> 
> In <~/.gitconfig>, add this section:
> 
>   [sendemail]
>   sendmailcmd = mutt -H -

A better approach for using git-send-email(1) with mutt(1) is:

$ cat /usr/bin/mutt-as-mta
#!/bin/sh
mutt -H -

And then in <~/.gitconfig>:

[sendemail]
sendmailcmd = mutt-as-mta

This avoids duplicate TO and CCs.

> 
> After this patch, all patches sent with git-send-mail(1) will be signed
> (and even encrypted, if we have the public keys of all recipients and
> have enabled encryption when possible).
> 
> This is breaking behavior, so it needs some more justification than just
> the above.
> 
> This wasn't possible at all with mutt, and is a quite basic operation.
> With current mutt(1), you'd need to do trickery with mailboxes to be
> able to open patches with mutt in interactive mode and sign/encrypt
> them.  One could say don't use git-send-email(1), but then you still
> need to open mutt(1) interactively for sending signed mail.  It is
> very useful to be able to send a long series of patches or any other
> mail without interaction, and have it all signed.
> 
> The reason for not enabling this was for allowing running mutt(1) in
> cron jobs, or other cases where the keyring can't be unlocked.  This
> would still be possible after this patch, although it would need a
> change in the configuration.  Users should have a different
> configuration for such cron jobs that doesn't ask mutt(1) to use PGP.
> 
> Link: <https://github.com/neomutt/neomutt/issues/1471>
> Link: <https://github.com/neomutt/neomutt/pull/1476>
> Co-developed-by: Jenya Sovetkin 
> Cc: 
> Signed-off-by: Alejandro Colomar 
> ---
> 
> Hi!
> 
> I've been trying this patch for a few days with real patches sent to
> mailing lists, and it's been working great.  This same patch is sent
> with this patch (and the suggested git-send-email(1) configuration).
> 
> I based this patch on work from Jenya in neomutt(1), which has similar
> code, so the patch was easy to translate to mutt(1)'s code.
> 
> Here's how a log from git-send-email(1) looks like after this patch:
> 
>   $ git send-email 
> patches/0001-CONTRIBUTING-Please-sign-your-emails-with-PGP.patch
> ...
>   Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y
>   Looking for keys matching "a...@kernel.org"...
>   OK. Log says:
>   Sendmail: mutt -H - -i a...@kernel.org
>   From: Alejandro Colomar 
>   To: a...@kernel.org
>   Subject: [PATCH] CONTRIBUTING: Please sign your emails with PGP
>   Date: Fri, 10 Nov 2023 01:16:46 +0100
>   Message-ID: <20231110001648.4787-1-...@kernel.org>
>   X-Mailer: git-send-email 2.42.0
>   MIME-Version: 1.0
>   Content-Transfer-Encoding: 8bit
> 
>   Result: OK
> 
> I'm CCing neomutt(1), since I intend to send a similar patch to them.
> 
> Also, I only subscribed to mutt-dev@ recently, so this message may not
> arrive to the list.  If so, please bounce it yourself there.
> 
> Thanks!
> Alex
> 
> 
>  send.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/send.c b/send.c
> index 21ecf041..c98773fc 100644
> --- a/send.c
> +++ b/send.c
> @@ -2248,13 +2248,11 @@ static int send_message_resume_first_edit 
> (SEND_CONTEXT *sctx)
> * 2) pgp: header field was present during message editing with 
> $edit_headers (sctx->msg->security != 0)
> * 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
> *
> * 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)))
> +  if (WithCrypto && (sctx->msg->security == 0) && !(sctx->flags & 
> (SENDPOSTPONED | SENDRESEND)))
>{
>  if (
>  #ifdef USE_AUTOCRYPT
> -- 
> 2.42.0
> 



-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

[PATCH] send.c: Allow crypto operations in batch and mailx modes.

[Alejandro Colomar]

This is useful for signing patches with git-send-email(1).  Here's a
working configuration for that:

In <~/.gitconfig>, add this section:

[sendemail]
sendmailcmd = mutt -H -

After this patch, all patches sent with git-send-mail(1) will be signed
(and even encrypted, if we have the public keys of all recipients and
have enabled encryption when possible).

This is breaking behavior, so it needs some more justification than just
the above.

This wasn't possible at all with mutt, and is a quite basic operation.
With current mutt(1), you'd need to do trickery with mailboxes to be
able to open patches with mutt in interactive mode and sign/encrypt
them.  One could say don't use git-send-email(1), but then you still
need to open mutt(1) interactively for sending signed mail.  It is
very useful to be able to send a long series of patches or any other
mail without interaction, and have it all signed.

The reason for not enabling this was for allowing running mutt(1) in
cron jobs, or other cases where the keyring can't be unlocked.  This
would still be possible after this patch, although it would need a
change in the configuration.  Users should have a different
configuration for such cron jobs that doesn't ask mutt(1) to use PGP.

Link: <https://github.com/neomutt/neomutt/issues/1471>
Link: <https://github.com/neomutt/neomutt/pull/1476>
Co-developed-by: Jenya Sovetkin 
Cc: 
Signed-off-by: Alejandro Colomar 
---

Hi!

I've been trying this patch for a few days with real patches sent to
mailing lists, and it's been working great.  This same patch is sent
with this patch (and the suggested git-send-email(1) configuration).

I based this patch on work from Jenya in neomutt(1), which has similar
code, so the patch was easy to translate to mutt(1)'s code.

Here's how a log from git-send-email(1) looks like after this patch:

$ git send-email 
patches/0001-CONTRIBUTING-Please-sign-your-emails-with-PGP.patch
...
Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y
Looking for keys matching "a...@kernel.org"...
OK. Log says:
Sendmail: mutt -H - -i a...@kernel.org
    From: Alejandro Colomar 
To: a...@kernel.org
Subject: [PATCH] CONTRIBUTING: Please sign your emails with PGP
Date: Fri, 10 Nov 2023 01:16:46 +0100
Message-ID: <20231110001648.4787-1-...@kernel.org>
X-Mailer: git-send-email 2.42.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: OK

I'm CCing neomutt(1), since I intend to send a similar patch to them.

Also, I only subscribed to mutt-dev@ recently, so this message may not
arrive to the list.  If so, please bounce it yourself there.

Thanks!
Alex


 send.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/send.c b/send.c
index 21ecf041..c98773fc 100644
--- a/send.c
+++ b/send.c
@@ -2248,13 +2248,11 @@ static int send_message_resume_first_edit (SEND_CONTEXT 
*sctx)
* 2) pgp: header field was present during message editing with 
$edit_headers (sctx->msg->security != 0)
* 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
*
* 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)))
+  if (WithCrypto && (sctx->msg->security == 0) && !(sctx->flags & 
(SENDPOSTPONED | SENDRESEND)))
   {
 if (
 #ifdef USE_AUTOCRYPT
-- 
2.42.0



signature.asc
Description: PGP signature