Re: Message security; protected header fields

2024-04-19 Thread 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

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

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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 > > >

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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 > >

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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,

Re: Message security; protected header fields

2024-04-19 Thread 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

[PATCH] Add $pager_min_index_lines config option.

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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,

Re: Message security; protected header fields

2024-04-19 Thread 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... >

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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,

Re: Message security; protected header fields

2024-04-19 Thread 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

Re: Message security; protected header fields

2024-04-19 Thread 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 >

Re: Message security; protected header fields

2024-04-19 Thread 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 > >