Re: Message security; protected header fields

[Kurt Hackenberg]

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


Are you both thinking of defining a new MIME type to hold only the 
protected headers?  I thought of that.  It seems cleaner...I see no 
mention of that in the draft we're talking about, not even to reject 
it.  I suppose old mail readers wouldn't know what to do with that new 
body part.  They might display it if it's a subtype of text.


Turns out an earlier way to protect headers was added in S/MIME 3.1.  
It puts the whole message, including the header section, in a body part 
of type message/rfc822, and wraps a crypto body part around that.  So 
the message contains a copy of itself, sort of.


The draft calls that mechanism "wrapped".  The draft wants to replace 
that with this header-stuffing thing because "legacy" mail readers are 
sometimes confused by the wrapped message.  The draft says 
header-stuffing is less likely to confuse mail readers that never heard 
of either scheme.



MIME header blocks are for MIME-specific metadata; even if no mail
clients actually break due to this, it still feels gross.


Agreed.

I would like to hold off on this until the draft becomes an RFC, if it does.

Re: [PATCH] crypt-gpgme.c: Fix NULL dereference

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 10:30:54PM +0200, Alejandro Colomar wrote:

We applied this patch to neomutt(1) a few months ago.  See the link in
the commit message for more details.  It's a cherry-pick of neomutt's
commit bd9ceb2a6442b966 ("ncrypt/crypt_gpgme.c: Fix NULL dereference").


Thank you for forwarding the commit.  I'll push it up today.

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


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Kevin J. McCarthy]

On Fri, Apr 19, 2024 at 05:07:17PM -0400, Derek Martin wrote:

On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.

Fair enough.


But--and I s'pose I may have just missed it--I don't recall seeing any
discussion of this feature on this list.  Learning of such things is
precisely why I'm on this list, so... I'm not sure whether it's better
(from my perspective) that I missed it, or if it never happened. =8^)


That's fair enough back.  I don't think I engaged the list in discussion 
of the change. :^)


What I did do was a minimal implementation of the spec at the time, so 
that Mutt could read messages from other clients that started sending 
with a hidden Subject header, for interoperability.


Writing was not enabled by default, but when enabled, it did send 
most/all of the spec listed headers (at the time), again for 
interoperability.


Doing "things" with other headers or even displaying them would open a 
big can of worms, so I kept the implementation minimal on purpose.


I don't have an opinion on the future direction Mutt takes here.  It 
wouldn't be hard to rip out the existing implementation, or to extend 
it.


However, I'll just remind everyone (again) that I'm definitely on my way 
out, completely, of Mutt development.  I stopped being a maintainer a 
couple years ago, and my time available just keeps getting less and 
less.  :-( I just don't have the time to participate anymore, not to 
mention review patches.


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


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


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[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

[Derek Martin]

On Fri, Apr 19, 2024 at 10:44:18AM -0400, Derek Martin wrote:
> On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> > However, saying that mutt adds those headers by accident or as a bug seems a
> > bit uninformed.
> 
> Fair enough.

But--and I s'pose I may have just missed it--I don't recall seeing any
discussion of this feature on this list.  Learning of such things is
precisely why I'm on this list, so... I'm not sure whether it's better
(from my perspective) that I missed it, or if it never happened. =8^)

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



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 10:10:13PM +0200, Alejandro Colomar wrote:
> 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?

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

> 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.  Outlook's long line
parsing can be called a defacto standard, because it's used by
millions, perhaps even billions of users every day.  These ain't.

And even if they were, just like Outlook's long line parsing, defacto
standards are often very bad standards.

And also, autocrypt DOES NOT use existing standard headers, so it
doesn't put standard headers in the MIME block.  That's an important
distinction which would not trigger any bug like the one I described
above.

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



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 09:58:42PM +0200, Alejandro Colomar wrote:
> 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.

To be clear, I love MIME.  I'm not trying to avoid it, and I think
Will's suggestion using MIME is absolutely fine.  I'm suggesting that
the existing implementation pollutes MIME, which should be avoided, as
it presents an opportunity for existing MIME-compliant mail readers to
be confused by RFC 822/2822/5322 headers being present in MIME header
blocks, which is not something any standard even hints at.  I'm not
saying any such clients exist, but given the vast array of clients, it
would be a challenge to prove that none do.  It's just bad practice
and should be avoided.

[The MIME spec says non-MIME headers can be present and should be
ignored, but it doesn't address handling duplicates of standard
headers, and it likely wouldn't occur to past implementers of MIME
that someone would want to do this... it's essentially undefined
behavior.  In most cases it probably should be fine, as long as
implementers were careful; but it's going to depend on how message
parsing / MIME header block parsing is implemented in each client.]

For the record, if this is important to you, I'm also not saying you
shouldn't implement it.  Kevin hinted he wouldn't be too keen on
working on adding this to Mutt, which is pretty consistent with Mutt's
history--maintainers have always leaned pretty conservative about
accepting patches, and for good reason.  And especially so as Mutt is
in maintenance mode.  But there's no reason you can't create them and
make them available to anyone who wants this.  That's something that's
also been a part of Mutt development for decades--I and many others
have maintained patches for Mutt for extended periods, some of which
eventually made it in, many of which did not. I'd just note that, as
it would be a subset of people who use Mutt and use Mutt's encryption
features--already a fairly rarified group--I suspect the audience for
such patches will be quite small indeed...

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



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

[Derek Martin]

On Fri, Apr 19, 2024 at 09:30:27PM +0200, Steffen Nurpmeso wrote:
> Derek Martin wrote in
>  <20240419191717.ge2...@bladeshadow.org>:
>  ...
>  |Secondly, there is a standard mechanism for adding non-standard
>  |headers to e-mail:  use the string "X-" before the thing, and add it
> 
> Not anymore since RFC 6648.

Eh... as far as I can tell that RFC is routinely ignored.  But fine,
just omit the "X-" and make sure the field names are unique.  This is
still allowed by RFC 5322.

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



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

[Derek Martin]

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

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.

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



signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Steffen Nurpmeso]

Derek Martin wrote in
 <20240419191717.ge2...@bladeshadow.org>:
 ...
 |Secondly, there is a standard mechanism for adding non-standard
 |headers to e-mail:  use the string "X-" before the thing, and add it

Not anymore since RFC 6648.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Message security; protected header fields

[Derek Martin]

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


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



signature.asc
Description: PGP signature

[PATCH] Add $pager_min_index_lines config option.

[Piotr Durlej]

Hi everyone,

as a matter of exercise, I've implemented a new mutt option (see the 
description in init.h for the details).

If you like it, please feel free to merge.

Kind regards,
Piotr Durlej

---
 globals.h |  1 +
 init.h| 14 ++
 pager.c   | 10 --
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/globals.h b/globals.h
index fd63bd43..e20c4739 100644
--- a/globals.h
+++ b/globals.h
@@ -236,6 +236,7 @@ WHERE short HistSize;
 WHERE short MenuContext;
 WHERE short PagerContext;
 WHERE short PagerIndexLines;
+WHERE short PagerMinIndexLines;
 WHERE short PagerSkipQuotedContext;
 WHERE short ReadInc;
 WHERE short ReflowWrap;
diff --git a/init.h b/init.h
index dcb664f8..0d3fe87c 100644
--- a/init.h
+++ b/init.h
@@ -2440,6 +2440,20 @@ struct option_t MuttVars[] = {
   ** is less than $$pager_index_lines, then the index will only use as
   ** many lines as it needs.
   */
+  { "pager_min_index_lines", DT_NUM, R_PAGER, {.p=&PagerMinIndexLines}, {.l=0} 
},
+  /*
+  ** .pp
+  ** Controls the \fIminimum\fP number of lines of the mini-index.
+  ** .pp
+  ** If the number of messages in the current folder is less than
+  ** $$pager_min_index_lines, then the index will be padded with empty lines,
+  ** allowing for a mini-index of a constant height.
+  ** This option is otherwise same as the $$pager_index_lines option.
+  ** .pp
+  ** When both $pager_min_index_lines and $pager_index_lines are set, the
+  ** $pager_min_index_lines option determines the minimum number of rows, and
+  ** the $pager_index_lines controls the maximum.
+  */
   { "pager_skip_quoted_context", DT_NUM, R_NONE, {.p=&PagerSkipQuotedContext}, 
{.l=0} },
   /*
   ** .pp
diff --git a/pager.c b/pager.c
index 8df571ab..40b49425 100644
--- a/pager.c
+++ b/pager.c
@@ -1819,11 +1819,14 @@ static void pager_menu_redraw (MUTTMENU *pager_menu)
 memcpy (rd->pager_status_window, MuttStatusWindow, sizeof(mutt_window_t));
 rd->index_status_window->rows = rd->index_window->rows = 0;
 
-if (IsHeader (rd->extra) && PagerIndexLines)
+if (IsHeader (rd->extra) && (PagerIndexLines || PagerMinIndexLines))
 {
   memcpy (rd->index_window, MuttIndexWindow, sizeof(mutt_window_t));
   rd->index_window->rows = rd->indexlen > 0 ? rd->indexlen - 1 : 0;
 
+  if (PagerMinIndexLines && rd->index_window->rows <= PagerMinIndexLines)
+rd->index_window->rows = PagerMinIndexLines - 1;
+
   if (option (OPTSTATUSONTOP))
   {
 memcpy (rd->index_status_window, MuttStatusWindow, 
sizeof(mutt_window_t));
@@ -1879,7 +1882,7 @@ static void pager_menu_redraw (MUTTMENU *pager_menu)
 }
 #endif
 
-if (IsHeader (rd->extra) && PagerIndexLines)
+if (IsHeader (rd->extra) && (PagerIndexLines || PagerMinIndexLines))
 {
   if (rd->index == NULL)
   {
@@ -1905,6 +1908,9 @@ static void pager_menu_redraw (MUTTMENU *pager_menu)
   else
 rd->index->top = rd->index->current - rd->indicator;
 
+  if (rd->index->top < 0)
+rd->index->top = 0;
+
   menu_redraw_index(rd->index);
 }
 
-- 
2.44.0

Re: Message security; protected header fields

[Will Yardley]

On Fri, Apr 19, 2024 at 06:51:20PM +0200, Alejandro Colomar 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.
> 
> The protected headers are part of the header area of the MIME part.
> They are not part of the body area.

Got it. I was looking at the draft implementation, where it appeared
that the subject was in a single line within the actual body of the
message. That makes a lot more sense to me.

w

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

Re: Message security; protected header fields

[Will Yardley]

On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote:
> 
> 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?

Agree about DKIM, and about the general nastiness of putting headers in
the message body (though I guess they are trying to solve problems at
different layers; if I'm understanding the theoretical problem
correctly, DKIM would pass since it's getting signed after the point
where the message is received by the MTA?)

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

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)

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 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, and in most
cases, probably can be handled via common sense.

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.

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.

/w

Re: Message security; protected header fields

[Derek Martin]

On Fri, Apr 19, 2024 at 10:41:58AM +0800, Kevin J. McCarthy wrote:
> However, saying that mutt adds those headers by accident or as a bug seems a
> bit uninformed.

Fair enough.

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



signature.asc
Description: PGP signature

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: 
> 
> DKIM: 

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

-- 



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

-- 



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

-- 



signature.asc
Description: PGP signature