* Re: injected body trailers
@ 2021-10-21 20:44 ` Konstantin Ryabitsev
0 siblings, 0 replies; 32+ messages in thread
From: Konstantin Ryabitsev @ 2021-10-21 20:44 UTC (permalink / raw)
To: Kees Cook; +Cc: tools, linux-arm-kernel
On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> Hi!
>
> So, I just saw a DKIM failure, and it was entirely justified. :)
>
> Grabbing thread from lore.kernel.org/all/20211021142516.1843042-1-ardb%40kernel.org/t.mbox.gz
> Checking for newer revisions on https://lore.kernel.org/all/
> Analyzing 1 messages in the thread
> Checking attestation on all messages, may take a moment...
> ---
> ✓ [PATCH] ARM: stackprotector: prefer compiler for TLS based per-task protector
> ✓ Signed: openpgp/ardb@kernel.org
You will notice that the openpgp signature passed. This is because we:
1. record the length of the original message when we're creating the signature
(see l=2495 in X-Developer-Signature)
2. if the initial validation fails and the body is longer than l=2495, we trim
the body to that number of bytes
3. if the trimmed validation passes, we use that version for the patch body
content, since that's clearly what the developer intended
> ✗ BADSIG: DKIM/kernel.org
> ✓ Signed: DKIM/lists.infradead.org (From: ardb@kernel.org)
> ---
>
> This is https://lore.kernel.org/all/20211021142516.1843042-1-ardb@kernel.org/
> and for some reason, the linux-arm-kernel mailing list is injecting a
> body trailer.
"For some reason" is really "that's the default for mailman-2". Mailman-2
belongs to a wholly different era and *can* be configured to be DKIM
compliant, but rarely is.
> I just downloaded this directly and removed the trailer, and the DKIM
> passed. This experience has raise a few questions...
>
> 1) Can (should) b4 grow logic to progressively strip lines off the end
> of a body until DKIM passes?
Ah, but then the lists.infradead.org DKIM will fail. Theoretically, we should
always prioritize the signature that is closest aligned with the From: header,
but that's not actually that straightforward, as DNS lookup and validation
rules can get really complex.
> 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> Who should authorize this change (rmk, Catalin)? And who can make
> the change (peterz)?
The relevant settings should be a) don't add any subject prefixes, b) don't
add anything to the body trailers, c) don't rewrite any other headers (to, cc,
reply-to, etc).
> (I realize now that all the mail from linux-arm-kernel has been
> getting dropped into my Spam folder -- I normally don't notice since
> I'm usually CCed directly or via some other list on things I wanted
> to see.)
>
> 3) Are there other lists for which lore is collecting emails where DKIM
> is persistently broken, and can we fix those lists too?
I would also note that lists.infradead.org should not really be adding its own
DKIM signature to messages it sends out. It doesn't really serve any purpose
unless the From: header is rewritten (but please don't do that either).
-K
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 20:44 ` Konstantin Ryabitsev
@ 2021-10-21 21:21 ` Kees Cook
-1 siblings, 0 replies; 32+ messages in thread
From: Kees Cook @ 2021-10-21 21:21 UTC (permalink / raw)
To: Konstantin Ryabitsev, Russell King, Catalin Marinas, Peter Zijlstra
Cc: tools, linux-arm-kernel
On Thu, Oct 21, 2021 at 04:44:59PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > Hi!
> >
> > So, I just saw a DKIM failure, and it was entirely justified. :)
> >
> > Grabbing thread from lore.kernel.org/all/20211021142516.1843042-1-ardb%40kernel.org/t.mbox.gz
> > Checking for newer revisions on https://lore.kernel.org/all/
> > Analyzing 1 messages in the thread
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✓ [PATCH] ARM: stackprotector: prefer compiler for TLS based per-task protector
> > ✓ Signed: openpgp/ardb@kernel.org
>
> You will notice that the openpgp signature passed. This is because we:
>
> 1. record the length of the original message when we're creating the signature
> (see l=2495 in X-Developer-Signature)
> 2. if the initial validation fails and the body is longer than l=2495, we trim
> the body to that number of bytes
> 3. if the trimmed validation passes, we use that version for the patch body
> content, since that's clearly what the developer intended
I suspected something like this was happening to make that one pass.
Nice.
>
> > ✗ BADSIG: DKIM/kernel.org
> > ✓ Signed: DKIM/lists.infradead.org (From: ardb@kernel.org)
> > ---
> >
> > This is https://lore.kernel.org/all/20211021142516.1843042-1-ardb@kernel.org/
> > and for some reason, the linux-arm-kernel mailing list is injecting a
> > body trailer.
>
> "For some reason" is really "that's the default for mailman-2". Mailman-2
> belongs to a wholly different era and *can* be configured to be DKIM
> compliant, but rarely is.
>
> > I just downloaded this directly and removed the trailer, and the DKIM
> > passed. This experience has raise a few questions...
> >
> > 1) Can (should) b4 grow logic to progressively strip lines off the end
> > of a body until DKIM passes?
>
> Ah, but then the lists.infradead.org DKIM will fail. Theoretically, we should
> always prioritize the signature that is closest aligned with the From: header,
> but that's not actually that straightforward, as DNS lookup and validation
> rules can get really complex.
Could each signature validation independently process the body, with
the smallest signed body being what is "produced"? i.e. GPG already
self-trims. DKIM could do the same, trying to find a matching body i.e. on
failure (slow path), trying trimming up to 10(?) lines progressively
looking for a match?
(Probably better is to just fix the mailing lists, but maybe this would
be useful for historical patch extraction? Dunno.)
>
> > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > Who should authorize this change (rmk, Catalin)? And who can make
> > the change (peterz)?
>
> The relevant settings should be a) don't add any subject prefixes, b) don't
> add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> reply-to, etc).
rmk, Catalin, Peter, can this get sorted out? Having mailing list
trailers is annoying beyond just DKIM breakage. :)
>
> > (I realize now that all the mail from linux-arm-kernel has been
> > getting dropped into my Spam folder -- I normally don't notice since
> > I'm usually CCed directly or via some other list on things I wanted
> > to see.)
> >
> > 3) Are there other lists for which lore is collecting emails where DKIM
> > is persistently broken, and can we fix those lists too?
>
> I would also note that lists.infradead.org should not really be adding its own
> DKIM signature to messages it sends out. It doesn't really serve any purpose
> unless the From: header is rewritten (but please don't do that either).
-Kees
--
Kees Cook
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 21:21 ` Kees Cook
0 siblings, 0 replies; 32+ messages in thread
From: Kees Cook @ 2021-10-21 21:21 UTC (permalink / raw)
To: Konstantin Ryabitsev, Russell King, Catalin Marinas, Peter Zijlstra
Cc: tools, linux-arm-kernel
On Thu, Oct 21, 2021 at 04:44:59PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > Hi!
> >
> > So, I just saw a DKIM failure, and it was entirely justified. :)
> >
> > Grabbing thread from lore.kernel.org/all/20211021142516.1843042-1-ardb%40kernel.org/t.mbox.gz
> > Checking for newer revisions on https://lore.kernel.org/all/
> > Analyzing 1 messages in the thread
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✓ [PATCH] ARM: stackprotector: prefer compiler for TLS based per-task protector
> > ✓ Signed: openpgp/ardb@kernel.org
>
> You will notice that the openpgp signature passed. This is because we:
>
> 1. record the length of the original message when we're creating the signature
> (see l=2495 in X-Developer-Signature)
> 2. if the initial validation fails and the body is longer than l=2495, we trim
> the body to that number of bytes
> 3. if the trimmed validation passes, we use that version for the patch body
> content, since that's clearly what the developer intended
I suspected something like this was happening to make that one pass.
Nice.
>
> > ✗ BADSIG: DKIM/kernel.org
> > ✓ Signed: DKIM/lists.infradead.org (From: ardb@kernel.org)
> > ---
> >
> > This is https://lore.kernel.org/all/20211021142516.1843042-1-ardb@kernel.org/
> > and for some reason, the linux-arm-kernel mailing list is injecting a
> > body trailer.
>
> "For some reason" is really "that's the default for mailman-2". Mailman-2
> belongs to a wholly different era and *can* be configured to be DKIM
> compliant, but rarely is.
>
> > I just downloaded this directly and removed the trailer, and the DKIM
> > passed. This experience has raise a few questions...
> >
> > 1) Can (should) b4 grow logic to progressively strip lines off the end
> > of a body until DKIM passes?
>
> Ah, but then the lists.infradead.org DKIM will fail. Theoretically, we should
> always prioritize the signature that is closest aligned with the From: header,
> but that's not actually that straightforward, as DNS lookup and validation
> rules can get really complex.
Could each signature validation independently process the body, with
the smallest signed body being what is "produced"? i.e. GPG already
self-trims. DKIM could do the same, trying to find a matching body i.e. on
failure (slow path), trying trimming up to 10(?) lines progressively
looking for a match?
(Probably better is to just fix the mailing lists, but maybe this would
be useful for historical patch extraction? Dunno.)
>
> > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > Who should authorize this change (rmk, Catalin)? And who can make
> > the change (peterz)?
>
> The relevant settings should be a) don't add any subject prefixes, b) don't
> add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> reply-to, etc).
rmk, Catalin, Peter, can this get sorted out? Having mailing list
trailers is annoying beyond just DKIM breakage. :)
>
> > (I realize now that all the mail from linux-arm-kernel has been
> > getting dropped into my Spam folder -- I normally don't notice since
> > I'm usually CCed directly or via some other list on things I wanted
> > to see.)
> >
> > 3) Are there other lists for which lore is collecting emails where DKIM
> > is persistently broken, and can we fix those lists too?
>
> I would also note that lists.infradead.org should not really be adding its own
> DKIM signature to messages it sends out. It doesn't really serve any purpose
> unless the From: header is rewritten (but please don't do that either).
-Kees
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 21:21 ` Kees Cook
@ 2021-10-21 21:29 ` Catalin Marinas
-1 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2021-10-21 21:29 UTC (permalink / raw)
To: Kees Cook
Cc: Konstantin Ryabitsev, Russell King, Peter Zijlstra, tools,
linux-arm-kernel, David Woodhouse
On Thu, Oct 21, 2021 at 02:21:04PM -0700, Kees Cook wrote:
> On Thu, Oct 21, 2021 at 04:44:59PM -0400, Konstantin Ryabitsev wrote:
> > On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > > Who should authorize this change (rmk, Catalin)? And who can make
> > > the change (peterz)?
> >
> > The relevant settings should be a) don't add any subject prefixes, b) don't
> > add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> > reply-to, etc).
>
> rmk, Catalin, Peter, can this get sorted out? Having mailing list
> trailers is annoying beyond just DKIM breakage. :)
That would be dwmw2, cc'ed.
--
Catalin
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 21:29 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2021-10-21 21:29 UTC (permalink / raw)
To: Kees Cook
Cc: Konstantin Ryabitsev, Russell King, Peter Zijlstra, tools,
linux-arm-kernel, David Woodhouse
On Thu, Oct 21, 2021 at 02:21:04PM -0700, Kees Cook wrote:
> On Thu, Oct 21, 2021 at 04:44:59PM -0400, Konstantin Ryabitsev wrote:
> > On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > > Who should authorize this change (rmk, Catalin)? And who can make
> > > the change (peterz)?
> >
> > The relevant settings should be a) don't add any subject prefixes, b) don't
> > add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> > reply-to, etc).
>
> rmk, Catalin, Peter, can this get sorted out? Having mailing list
> trailers is annoying beyond just DKIM breakage. :)
That would be dwmw2, cc'ed.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 20:44 ` Konstantin Ryabitsev
@ 2021-10-21 21:42 ` David Woodhouse
-1 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 21:42 UTC (permalink / raw)
To: Konstantin Ryabitsev, Kees Cook; +Cc: tools, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 4608 bytes --]
On Thu, 2021-10-21 at 16:44 -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > Hi!
> >
> > So, I just saw a DKIM failure, and it was entirely justified. :)
> >
> > Grabbing thread from lore.kernel.org/all/20211021142516.1843042-1-ardb%40kernel.org/t.mbox.gz
> > Checking for newer revisions on
> > https://lore.kernel.org/all/
> >
> > Analyzing 1 messages in the thread
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✓ [PATCH] ARM: stackprotector: prefer compiler for TLS based per-task protector
> > ✓ Signed: openpgp/
> > ardb@kernel.org
> >
>
> You will notice that the openpgp signature passed. This is because we:
>
> 1. record the length of the original message when we're creating the signature
> (see l=2495 in X-Developer-Signature)
> 2. if the initial validation fails and the body is longer than l=2495, we trim
> the body to that number of bytes
> 3. if the trimmed validation passes, we use that version for the patch body
> content, since that's clearly what the developer intended
>
All this was known when DKIM was first invented, and the fact that DKIM
signatures would break with fairly much all mailing lists was also
known, the moment they decided to go ahead with DKIM in its current
state without any solution for it.
> > ✗ BADSIG: DKIM/kernel.org
> > ✓ Signed: DKIM/lists.infradead.org (From: ardb@kernel.org)
Hm. I thought I had configured mailman to *remove* older DKIM
signatures (which are going to be broken). The message you receive
should *only* have the newly-added signature corresponding to the
Sender: of the message. The original one was superseded by the new one
and should have been removed.
> >
> > This is
> > https://lore.kernel.org/all/20211021142516.1843042-1-ardb@kernel.org/
> >
> > and for some reason, the linux-arm-kernel mailing list is injecting a
> > body trailer.
>
> "For some reason" is really "that's the default for mailman-2". Mailman-2
> belongs to a wholly different era and *can* be configured to be DKIM
> compliant, but rarely is.
>
That's what mailing lists have always done, because users are stupid
and need to be reminded in *every* single message that this is a
mailing list and this is how they unsubscribe. Really, even *with* that
reminder there are plenty of people who can't work it out.
> > I just downloaded this directly and removed the trailer, and the DKIM
> > passed. This experience has raise a few questions...
> >
> > 1) Can (should) b4 grow logic to progressively strip lines off the end
> > of a body until DKIM passes?
>
> Ah, but then the lists.infradead.org DKIM will fail. Theoretically, we should
> always prioritize the signature that is closest aligned with the From: header,
> but that's not actually that straightforward, as DNS lookup and validation
> rules can get really complex.
>
Surely the Sender: header should take priority. That one would work.
> > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > Who should authorize this change (rmk, Catalin)? And who can make
> > the change (peterz)?
>
I run the host but per-list settings are up to the admin of the
individual list. For the lak list, vince@kyllikki.org and
mouw@nl.linux.org are listed as admins. I don't know if that
corresponds with who actually remembers the list password these days; I
can set a new one and provide it if that's helpful.
> The relevant settings should be a) don't add any subject prefixes, b) don't
> add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> reply-to, etc).
>
> > (I realize now that all the mail from linux-arm-kernel has been
> > getting dropped into my Spam folder -- I normally don't notice since
> > I'm usually CCed directly or via some other list on things I wanted
> > to see.)
> >
> > 3) Are there other lists for which lore is collecting emails where DKIM
> > is persistently broken, and can we fix those lists too?
>
> I would also note that lists.infradead.org should not really be adding its own
> DKIM signature to messages it sends out. It doesn't really serve any purpose
> unless the From: header is rewritten (but please don't do that either).
No, it matches the Sender: header, which is the entity that actually
submitted the mail to the system (as opposed to the possibly multiple
entities listed in the From: header, which are merely authors of the
message).
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 21:42 ` David Woodhouse
0 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 21:42 UTC (permalink / raw)
To: Konstantin Ryabitsev, Kees Cook; +Cc: tools, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 4608 bytes --]
On Thu, 2021-10-21 at 16:44 -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 21, 2021 at 01:22:31PM -0700, Kees Cook wrote:
> > Hi!
> >
> > So, I just saw a DKIM failure, and it was entirely justified. :)
> >
> > Grabbing thread from lore.kernel.org/all/20211021142516.1843042-1-ardb%40kernel.org/t.mbox.gz
> > Checking for newer revisions on
> > https://lore.kernel.org/all/
> >
> > Analyzing 1 messages in the thread
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✓ [PATCH] ARM: stackprotector: prefer compiler for TLS based per-task protector
> > ✓ Signed: openpgp/
> > ardb@kernel.org
> >
>
> You will notice that the openpgp signature passed. This is because we:
>
> 1. record the length of the original message when we're creating the signature
> (see l=2495 in X-Developer-Signature)
> 2. if the initial validation fails and the body is longer than l=2495, we trim
> the body to that number of bytes
> 3. if the trimmed validation passes, we use that version for the patch body
> content, since that's clearly what the developer intended
>
All this was known when DKIM was first invented, and the fact that DKIM
signatures would break with fairly much all mailing lists was also
known, the moment they decided to go ahead with DKIM in its current
state without any solution for it.
> > ✗ BADSIG: DKIM/kernel.org
> > ✓ Signed: DKIM/lists.infradead.org (From: ardb@kernel.org)
Hm. I thought I had configured mailman to *remove* older DKIM
signatures (which are going to be broken). The message you receive
should *only* have the newly-added signature corresponding to the
Sender: of the message. The original one was superseded by the new one
and should have been removed.
> >
> > This is
> > https://lore.kernel.org/all/20211021142516.1843042-1-ardb@kernel.org/
> >
> > and for some reason, the linux-arm-kernel mailing list is injecting a
> > body trailer.
>
> "For some reason" is really "that's the default for mailman-2". Mailman-2
> belongs to a wholly different era and *can* be configured to be DKIM
> compliant, but rarely is.
>
That's what mailing lists have always done, because users are stupid
and need to be reminded in *every* single message that this is a
mailing list and this is how they unsubscribe. Really, even *with* that
reminder there are plenty of people who can't work it out.
> > I just downloaded this directly and removed the trailer, and the DKIM
> > passed. This experience has raise a few questions...
> >
> > 1) Can (should) b4 grow logic to progressively strip lines off the end
> > of a body until DKIM passes?
>
> Ah, but then the lists.infradead.org DKIM will fail. Theoretically, we should
> always prioritize the signature that is closest aligned with the From: header,
> but that's not actually that straightforward, as DNS lookup and validation
> rules can get really complex.
>
Surely the Sender: header should take priority. That one would work.
> > 2) Can the linux-arm-kernel mailing list please stop breaking DKIM?
> > Who should authorize this change (rmk, Catalin)? And who can make
> > the change (peterz)?
>
I run the host but per-list settings are up to the admin of the
individual list. For the lak list, vince@kyllikki.org and
mouw@nl.linux.org are listed as admins. I don't know if that
corresponds with who actually remembers the list password these days; I
can set a new one and provide it if that's helpful.
> The relevant settings should be a) don't add any subject prefixes, b) don't
> add anything to the body trailers, c) don't rewrite any other headers (to, cc,
> reply-to, etc).
>
> > (I realize now that all the mail from linux-arm-kernel has been
> > getting dropped into my Spam folder -- I normally don't notice since
> > I'm usually CCed directly or via some other list on things I wanted
> > to see.)
> >
> > 3) Are there other lists for which lore is collecting emails where DKIM
> > is persistently broken, and can we fix those lists too?
>
> I would also note that lists.infradead.org should not really be adding its own
> DKIM signature to messages it sends out. It doesn't really serve any purpose
> unless the From: header is rewritten (but please don't do that either).
No, it matches the Sender: header, which is the entity that actually
submitted the mail to the system (as opposed to the possibly multiple
entities listed in the From: header, which are merely authors of the
message).
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 21:42 ` David Woodhouse
@ 2021-10-21 22:57 ` Konstantin Ryabitsev
-1 siblings, 0 replies; 32+ messages in thread
From: Konstantin Ryabitsev @ 2021-10-21 22:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: Kees Cook, tools, linux-arm-kernel
On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > > (I realize now that all the mail from linux-arm-kernel has been
> > > getting dropped into my Spam folder -- I normally don't notice since
> > > I'm usually CCed directly or via some other list on things I wanted
> > > to see.)
> > >
> > > 3) Are there other lists for which lore is collecting emails where DKIM
> > > is persistently broken, and can we fix those lists too?
> >
> > I would also note that lists.infradead.org should not really be adding its own
> > DKIM signature to messages it sends out. It doesn't really serve any purpose
> > unless the From: header is rewritten (but please don't do that either).
>
> No, it matches the Sender: header, which is the entity that actually
> submitted the mail to the system (as opposed to the possibly multiple
> entities listed in the From: header, which are merely authors of the
> message).
I know that's how it was envisioned to work (it's in the DKIM RFC as
recommendation for mailing list operators), but this didn't make it into the
DMARC standard -- DMARC intentionally ignores the Sender: header and will
*always* look at the From: header when performing DKIM validation.
(https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.3)
It was a bad idea in the first place, if you think about it. I can take any
message, add a Sender: header for the domain that I control and force the
validating system to check the DKIM-Signature header that I injected instead
of the signature from the originating domain, thus making any message I touch
pass DMARC verification.
So, I have to double-down on my statement that adding a lists.infradead.org
DKIM signature doesn't actually serve any purpose, at least not when it comes
to appeasing DMARC filters.
-K
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 22:57 ` Konstantin Ryabitsev
0 siblings, 0 replies; 32+ messages in thread
From: Konstantin Ryabitsev @ 2021-10-21 22:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: Kees Cook, tools, linux-arm-kernel
On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > > (I realize now that all the mail from linux-arm-kernel has been
> > > getting dropped into my Spam folder -- I normally don't notice since
> > > I'm usually CCed directly or via some other list on things I wanted
> > > to see.)
> > >
> > > 3) Are there other lists for which lore is collecting emails where DKIM
> > > is persistently broken, and can we fix those lists too?
> >
> > I would also note that lists.infradead.org should not really be adding its own
> > DKIM signature to messages it sends out. It doesn't really serve any purpose
> > unless the From: header is rewritten (but please don't do that either).
>
> No, it matches the Sender: header, which is the entity that actually
> submitted the mail to the system (as opposed to the possibly multiple
> entities listed in the From: header, which are merely authors of the
> message).
I know that's how it was envisioned to work (it's in the DKIM RFC as
recommendation for mailing list operators), but this didn't make it into the
DMARC standard -- DMARC intentionally ignores the Sender: header and will
*always* look at the From: header when performing DKIM validation.
(https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.3)
It was a bad idea in the first place, if you think about it. I can take any
message, add a Sender: header for the domain that I control and force the
validating system to check the DKIM-Signature header that I injected instead
of the signature from the originating domain, thus making any message I touch
pass DMARC verification.
So, I have to double-down on my statement that adding a lists.infradead.org
DKIM signature doesn't actually serve any purpose, at least not when it comes
to appeasing DMARC filters.
-K
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 22:57 ` Konstantin Ryabitsev
@ 2021-10-21 23:00 ` David Woodhouse
-1 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 23:00 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Kees Cook, tools, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
On Thu, 2021-10-21 at 18:57 -0400, Konstantin Ryabitsev wrote:
> thus making any message I touch pass DMARC verification.
Er… "thus making any message I *send* pass DMARC verification".
The Sender is the entity who sends the message. Who submits the message
to the mail system for transport. The Sender in this case is Mailman,
and the DKIM signature correctly passes verification.
All else is based on a fundamental misunderstanding of what the Sender:
and From: headers actually mean.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 23:00 ` David Woodhouse
0 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 23:00 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Kees Cook, tools, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]
On Thu, 2021-10-21 at 18:57 -0400, Konstantin Ryabitsev wrote:
> thus making any message I touch pass DMARC verification.
Er… "thus making any message I *send* pass DMARC verification".
The Sender is the entity who sends the message. Who submits the message
to the mail system for transport. The Sender in this case is Mailman,
and the DKIM signature correctly passes verification.
All else is based on a fundamental misunderstanding of what the Sender:
and From: headers actually mean.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 23:00 ` David Woodhouse
@ 2021-10-21 23:33 ` Konstantin Ryabitsev
-1 siblings, 0 replies; 32+ messages in thread
From: Konstantin Ryabitsev @ 2021-10-21 23:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: Kees Cook, tools, linux-arm-kernel
On Fri, Oct 22, 2021 at 12:00:43AM +0100, David Woodhouse wrote:
> > thus making any message I touch pass DMARC verification.
>
>
> Er… "thus making any message I *send* pass DMARC verification".
>
> The Sender is the entity who sends the message. Who submits the message
> to the mail system for transport. The Sender in this case is Mailman,
> and the DKIM signature correctly passes verification.
>
> All else is based on a fundamental misunderstanding of what the Sender:
> and From: headers actually mean.
David, I'm happy to argue whether this makes sense or not, but the fact of the
matter remains that DMARC specifically ignores the Sender: header, so any
email gateway performing DMARC validation will mark messages sent by
lists.infradead.org as failing the check. Unfortunately, anti-phishing
policies at many companies increasingly quarantine or reject messages failing
DMARC verification, so DMARC non-compliant mail will be increasingly not
received by list subscribers.
DMARC and mailing lists are not mutually incompatible, but to make it work
correctly the list operators must either not touch the message bodies and any
pre-existing headers, or rewrite From: to be coming from the mailing list
domain. In the context of patches, I would strongly argue that the former is
the only reasonable solution.
-K
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 23:33 ` Konstantin Ryabitsev
0 siblings, 0 replies; 32+ messages in thread
From: Konstantin Ryabitsev @ 2021-10-21 23:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: Kees Cook, tools, linux-arm-kernel
On Fri, Oct 22, 2021 at 12:00:43AM +0100, David Woodhouse wrote:
> > thus making any message I touch pass DMARC verification.
>
>
> Er… "thus making any message I *send* pass DMARC verification".
>
> The Sender is the entity who sends the message. Who submits the message
> to the mail system for transport. The Sender in this case is Mailman,
> and the DKIM signature correctly passes verification.
>
> All else is based on a fundamental misunderstanding of what the Sender:
> and From: headers actually mean.
David, I'm happy to argue whether this makes sense or not, but the fact of the
matter remains that DMARC specifically ignores the Sender: header, so any
email gateway performing DMARC validation will mark messages sent by
lists.infradead.org as failing the check. Unfortunately, anti-phishing
policies at many companies increasingly quarantine or reject messages failing
DMARC verification, so DMARC non-compliant mail will be increasingly not
received by list subscribers.
DMARC and mailing lists are not mutually incompatible, but to make it work
correctly the list operators must either not touch the message bodies and any
pre-existing headers, or rewrite From: to be coming from the mailing list
domain. In the context of patches, I would strongly argue that the former is
the only reasonable solution.
-K
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 23:33 ` Konstantin Ryabitsev
@ 2021-10-21 23:41 ` David Woodhouse
-1 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 23:41 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Kees Cook, tools, linux-arm-kernel
On 22 October 2021 00:33:02 BST, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
>On Fri, Oct 22, 2021 at 12:00:43AM +0100, David Woodhouse wrote:
>> > thus making any message I touch pass DMARC verification.
>>
>>
>> Er… "thus making any message I *send* pass DMARC verification".
>>
>> The Sender is the entity who sends the message. Who submits the message
>> to the mail system for transport. The Sender in this case is Mailman,
>> and the DKIM signature correctly passes verification.
>>
>> All else is based on a fundamental misunderstanding of what the Sender:
>> and From: headers actually mean.
>
>David, I'm happy to argue whether this makes sense or not, but the fact of the
>matter remains that DMARC specifically ignores the Sender: header, so any
>email gateway performing DMARC validation will mark messages sent by
>lists.infradead.org as failing the check. Unfortunately, anti-phishing
>policies at many companies increasingly quarantine or reject messages failing
>DMARC verification, so DMARC non-compliant mail will be increasingly not
>received by list subscribers.
>
>DMARC and mailing lists are not mutually incompatible, but to make it work
>correctly the list operators must either not touch the message bodies and any
>pre-existing headers, or rewrite From: to be coming from the mailing list
>domain. In the context of patches, I would strongly argue that the former is
>the only reasonable solution.
The only reasonable solution to the fact that DKIM/DMARC is fundamentally misdesigned, and failed to adopt any of the known workarounds that were being floated during its inception? That like so many of the other email snake oil "solutions", it required widescale changes in how email operates in the real world, in order to make its false assumptions come true?
I would posit that another reasonable "solution" to that problem is *not* to pander to its stupidity, but instead just declare it "yet another bad idea on the Internet" and ignore it.
But it's up to the owner of the individual mailing list. Nothing prevents them from configuring it as DMARC demands. Unless they've forgotten the list password, in which case I can reset it for them.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-21 23:41 ` David Woodhouse
0 siblings, 0 replies; 32+ messages in thread
From: David Woodhouse @ 2021-10-21 23:41 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Kees Cook, tools, linux-arm-kernel
On 22 October 2021 00:33:02 BST, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
>On Fri, Oct 22, 2021 at 12:00:43AM +0100, David Woodhouse wrote:
>> > thus making any message I touch pass DMARC verification.
>>
>>
>> Er… "thus making any message I *send* pass DMARC verification".
>>
>> The Sender is the entity who sends the message. Who submits the message
>> to the mail system for transport. The Sender in this case is Mailman,
>> and the DKIM signature correctly passes verification.
>>
>> All else is based on a fundamental misunderstanding of what the Sender:
>> and From: headers actually mean.
>
>David, I'm happy to argue whether this makes sense or not, but the fact of the
>matter remains that DMARC specifically ignores the Sender: header, so any
>email gateway performing DMARC validation will mark messages sent by
>lists.infradead.org as failing the check. Unfortunately, anti-phishing
>policies at many companies increasingly quarantine or reject messages failing
>DMARC verification, so DMARC non-compliant mail will be increasingly not
>received by list subscribers.
>
>DMARC and mailing lists are not mutually incompatible, but to make it work
>correctly the list operators must either not touch the message bodies and any
>pre-existing headers, or rewrite From: to be coming from the mailing list
>domain. In the context of patches, I would strongly argue that the former is
>the only reasonable solution.
The only reasonable solution to the fact that DKIM/DMARC is fundamentally misdesigned, and failed to adopt any of the known workarounds that were being floated during its inception? That like so many of the other email snake oil "solutions", it required widescale changes in how email operates in the real world, in order to make its false assumptions come true?
I would posit that another reasonable "solution" to that problem is *not* to pander to its stupidity, but instead just declare it "yet another bad idea on the Internet" and ignore it.
But it's up to the owner of the individual mailing list. Nothing prevents them from configuring it as DMARC demands. Unless they've forgotten the list password, in which case I can reset it for them.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-21 21:42 ` David Woodhouse
@ 2021-10-22 3:53 ` Kees Cook
-1 siblings, 0 replies; 32+ messages in thread
From: Kees Cook @ 2021-10-22 3:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Konstantin Ryabitsev, tools, linux-arm-kernel, Russell King,
Catalin Marinas, Will Deacon, Arnd Bergmann, Olof Johansson
On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> I run the host but per-list settings are up to the admin of the
> individual list. For the lak list, vince@kyllikki.org and
> mouw@nl.linux.org are listed as admins. I don't know if that
> corresponds with who actually remembers the list password these days; I
> can set a new one and provide it if that's helpful.
$ grep -Ei '(kyllikki|mouw@)' MAINTAINERS .mailmap | wc -l
0
$ grep linux-arm-kernel@lists.infradead.org MAINTAINERS | wc -l
157
How about we reset that password and make the following folks the
list admins, assuming they're interested:
ARM PORT
M: Russell King <linux@armlinux.org.uk>
ARM64 PORT (AARCH64 ARCHITECTURE)
M: Catalin Marinas <catalin.marinas@arm.com>
M: Will Deacon <will@kernel.org>
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
M: Arnd Bergmann <arnd@arndb.de>
M: Olof Johansson <olof@lixom.net>
--
Kees Cook
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-22 3:53 ` Kees Cook
0 siblings, 0 replies; 32+ messages in thread
From: Kees Cook @ 2021-10-22 3:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Konstantin Ryabitsev, tools, linux-arm-kernel, Russell King,
Catalin Marinas, Will Deacon, Arnd Bergmann, Olof Johansson
On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> I run the host but per-list settings are up to the admin of the
> individual list. For the lak list, vince@kyllikki.org and
> mouw@nl.linux.org are listed as admins. I don't know if that
> corresponds with who actually remembers the list password these days; I
> can set a new one and provide it if that's helpful.
$ grep -Ei '(kyllikki|mouw@)' MAINTAINERS .mailmap | wc -l
0
$ grep linux-arm-kernel@lists.infradead.org MAINTAINERS | wc -l
157
How about we reset that password and make the following folks the
list admins, assuming they're interested:
ARM PORT
M: Russell King <linux@armlinux.org.uk>
ARM64 PORT (AARCH64 ARCHITECTURE)
M: Catalin Marinas <catalin.marinas@arm.com>
M: Will Deacon <will@kernel.org>
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
M: Arnd Bergmann <arnd@arndb.de>
M: Olof Johansson <olof@lixom.net>
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-22 3:53 ` Kees Cook
@ 2021-10-22 7:32 ` Russell King (Oracle)
-1 siblings, 0 replies; 32+ messages in thread
From: Russell King (Oracle) @ 2021-10-22 7:32 UTC (permalink / raw)
To: Kees Cook
Cc: David Woodhouse, Konstantin Ryabitsev, tools, linux-arm-kernel,
Catalin Marinas, Will Deacon, Arnd Bergmann, Olof Johansson
On Thu, Oct 21, 2021 at 08:53:09PM -0700, Kees Cook wrote:
> On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > I run the host but per-list settings are up to the admin of the
> > individual list. For the lak list, vince@kyllikki.org and
> > mouw@nl.linux.org are listed as admins. I don't know if that
> > corresponds with who actually remembers the list password these days; I
> > can set a new one and provide it if that's helpful.
>
> $ grep -Ei '(kyllikki|mouw@)' MAINTAINERS .mailmap | wc -l
> 0
> $ grep linux-arm-kernel@lists.infradead.org MAINTAINERS | wc -l
> 157
>
> How about we reset that password and make the following folks the
> list admins, assuming they're interested:
>
> ARM PORT
> M: Russell King <linux@armlinux.org.uk>
No thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-22 7:32 ` Russell King (Oracle)
0 siblings, 0 replies; 32+ messages in thread
From: Russell King (Oracle) @ 2021-10-22 7:32 UTC (permalink / raw)
To: Kees Cook
Cc: David Woodhouse, Konstantin Ryabitsev, tools, linux-arm-kernel,
Catalin Marinas, Will Deacon, Arnd Bergmann, Olof Johansson
On Thu, Oct 21, 2021 at 08:53:09PM -0700, Kees Cook wrote:
> On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > I run the host but per-list settings are up to the admin of the
> > individual list. For the lak list, vince@kyllikki.org and
> > mouw@nl.linux.org are listed as admins. I don't know if that
> > corresponds with who actually remembers the list password these days; I
> > can set a new one and provide it if that's helpful.
>
> $ grep -Ei '(kyllikki|mouw@)' MAINTAINERS .mailmap | wc -l
> 0
> $ grep linux-arm-kernel@lists.infradead.org MAINTAINERS | wc -l
> 157
>
> How about we reset that password and make the following folks the
> list admins, assuming they're interested:
>
> ARM PORT
> M: Russell King <linux@armlinux.org.uk>
No thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-22 3:53 ` Kees Cook
@ 2021-10-22 8:05 ` Arnd Bergmann
-1 siblings, 0 replies; 32+ messages in thread
From: Arnd Bergmann @ 2021-10-22 8:05 UTC (permalink / raw)
To: Kees Cook
Cc: David Woodhouse, Konstantin Ryabitsev, tools, Linux ARM,
Russell King, Catalin Marinas, Will Deacon, Arnd Bergmann,
Olof Johansson
On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
>
> How about we reset that password and make the following folks the
> list admins, assuming they're interested:
>
> ARM64 PORT (AARCH64 ARCHITECTURE)
> M: Catalin Marinas <catalin.marinas@arm.com>
> M: Will Deacon <will@kernel.org>
>
> ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> M: Arnd Bergmann <arnd@arndb.de>
> M: Olof Johansson <olof@lixom.net>
Fine with me, as long as I'm not the only one.
Arnd
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: injected body trailers
@ 2021-10-22 8:05 ` Arnd Bergmann
0 siblings, 0 replies; 32+ messages in thread
From: Arnd Bergmann @ 2021-10-22 8:05 UTC (permalink / raw)
To: Kees Cook
Cc: David Woodhouse, Konstantin Ryabitsev, tools, Linux ARM,
Russell King, Catalin Marinas, Will Deacon, Arnd Bergmann,
Olof Johansson
On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
>
> How about we reset that password and make the following folks the
> list admins, assuming they're interested:
>
> ARM64 PORT (AARCH64 ARCHITECTURE)
> M: Catalin Marinas <catalin.marinas@arm.com>
> M: Will Deacon <will@kernel.org>
>
> ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> M: Arnd Bergmann <arnd@arndb.de>
> M: Olof Johansson <olof@lixom.net>
Fine with me, as long as I'm not the only one.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: injected body trailers
2021-10-22 8:05 ` Arnd Bergmann
@ 2021-10-22 9:41 ` Ard Biesheuvel
-1 siblings, 0 replies; 32+ messages in thread
From: Ard Biesheuvel @ 2021-10-22 9:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kees Cook, David Woodhouse, Konstantin Ryabitsev, tools,
Linux ARM, Russell King, Catalin Marinas, Will Deacon,
Olof Johansson
On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> >
> > How about we reset that password and make the following folks the
> > list admins, assuming they're interested:
> >
> > ARM64 PORT (AARCH64 ARCHITECTURE)
> > M: Catalin Marinas <catalin.marinas@arm.com>
> > M: Will Deacon <will@kernel.org>
> >
> > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > M: Arnd Bergmann <arnd@arndb.de>
> > M: Olof Johansson <olof@lixom.net>
>
> Fine with me, as long as I'm not the only one.
>
I'm happy to help out if needed.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-22 9:41 ` Ard Biesheuvel
0 siblings, 0 replies; 32+ messages in thread
From: Ard Biesheuvel @ 2021-10-22 9:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kees Cook, David Woodhouse, Konstantin Ryabitsev, tools,
Linux ARM, Russell King, Catalin Marinas, Will Deacon,
Olof Johansson
On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> >
> > How about we reset that password and make the following folks the
> > list admins, assuming they're interested:
> >
> > ARM64 PORT (AARCH64 ARCHITECTURE)
> > M: Catalin Marinas <catalin.marinas@arm.com>
> > M: Will Deacon <will@kernel.org>
> >
> > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > M: Arnd Bergmann <arnd@arndb.de>
> > M: Olof Johansson <olof@lixom.net>
>
> Fine with me, as long as I'm not the only one.
>
I'm happy to help out if needed.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-22 9:41 ` Ard Biesheuvel
@ 2021-10-22 11:43 ` Catalin Marinas
-1 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2021-10-22 11:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Arnd Bergmann, Kees Cook, David Woodhouse, Konstantin Ryabitsev,
tools, Linux ARM, Russell King, Will Deacon, Olof Johansson
On Fri, Oct 22, 2021 at 11:41:30AM +0200, Ard Biesheuvel wrote:
> On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > >
> > > How about we reset that password and make the following folks the
> > > list admins, assuming they're interested:
> > >
> > > ARM64 PORT (AARCH64 ARCHITECTURE)
> > > M: Catalin Marinas <catalin.marinas@arm.com>
> > > M: Will Deacon <will@kernel.org>
> > >
> > > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > > M: Arnd Bergmann <arnd@arndb.de>
> > > M: Olof Johansson <olof@lixom.net>
> >
> > Fine with me, as long as I'm not the only one.
> >
>
> I'm happy to help out if needed.
Same here.
--
Catalin
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-22 11:43 ` Catalin Marinas
0 siblings, 0 replies; 32+ messages in thread
From: Catalin Marinas @ 2021-10-22 11:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Arnd Bergmann, Kees Cook, David Woodhouse, Konstantin Ryabitsev,
tools, Linux ARM, Russell King, Will Deacon, Olof Johansson
On Fri, Oct 22, 2021 at 11:41:30AM +0200, Ard Biesheuvel wrote:
> On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > >
> > > How about we reset that password and make the following folks the
> > > list admins, assuming they're interested:
> > >
> > > ARM64 PORT (AARCH64 ARCHITECTURE)
> > > M: Catalin Marinas <catalin.marinas@arm.com>
> > > M: Will Deacon <will@kernel.org>
> > >
> > > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > > M: Arnd Bergmann <arnd@arndb.de>
> > > M: Olof Johansson <olof@lixom.net>
> >
> > Fine with me, as long as I'm not the only one.
> >
>
> I'm happy to help out if needed.
Same here.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
2021-10-22 11:43 ` Catalin Marinas
@ 2021-10-26 8:30 ` Will Deacon
-1 siblings, 0 replies; 32+ messages in thread
From: Will Deacon @ 2021-10-26 8:30 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ard Biesheuvel, Arnd Bergmann, Kees Cook, David Woodhouse,
Konstantin Ryabitsev, tools, Linux ARM, Russell King,
Olof Johansson
On Fri, Oct 22, 2021 at 12:43:38PM +0100, Catalin Marinas wrote:
> On Fri, Oct 22, 2021 at 11:41:30AM +0200, Ard Biesheuvel wrote:
> > On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > > > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > > >
> > > > How about we reset that password and make the following folks the
> > > > list admins, assuming they're interested:
> > > >
> > > > ARM64 PORT (AARCH64 ARCHITECTURE)
> > > > M: Catalin Marinas <catalin.marinas@arm.com>
> > > > M: Will Deacon <will@kernel.org>
> > > >
> > > > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > > > M: Arnd Bergmann <arnd@arndb.de>
> > > > M: Olof Johansson <olof@lixom.net>
> > >
> > > Fine with me, as long as I'm not the only one.
> > >
> >
> > I'm happy to help out if needed.
>
> Same here.
Likewise, with the disclaimer that I haven't helped to manage a mailing
list before!
An alternative would be to move the list to vger, but I suspect that's
far too invasive.
Will
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: injected body trailers
@ 2021-10-26 8:30 ` Will Deacon
0 siblings, 0 replies; 32+ messages in thread
From: Will Deacon @ 2021-10-26 8:30 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ard Biesheuvel, Arnd Bergmann, Kees Cook, David Woodhouse,
Konstantin Ryabitsev, tools, Linux ARM, Russell King,
Olof Johansson
On Fri, Oct 22, 2021 at 12:43:38PM +0100, Catalin Marinas wrote:
> On Fri, Oct 22, 2021 at 11:41:30AM +0200, Ard Biesheuvel wrote:
> > On Fri, 22 Oct 2021 at 10:16, Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Oct 22, 2021 at 5:53 AM Kees Cook <keescook@chromium.org> wrote:
> > > > On Thu, Oct 21, 2021 at 10:42:46PM +0100, David Woodhouse wrote:
> > > >
> > > > How about we reset that password and make the following folks the
> > > > list admins, assuming they're interested:
> > > >
> > > > ARM64 PORT (AARCH64 ARCHITECTURE)
> > > > M: Catalin Marinas <catalin.marinas@arm.com>
> > > > M: Will Deacon <will@kernel.org>
> > > >
> > > > ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
> > > > M: Arnd Bergmann <arnd@arndb.de>
> > > > M: Olof Johansson <olof@lixom.net>
> > >
> > > Fine with me, as long as I'm not the only one.
> > >
> >
> > I'm happy to help out if needed.
>
> Same here.
Likewise, with the disclaimer that I haven't helped to manage a mailing
list before!
An alternative would be to move the list to vger, but I suspect that's
far too invasive.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread