Re: [Tech Topic] Integrating GitLab into the Red Hat kernel workflow

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Mon, Jul 12, 2021 at 09:58:35AM -0400, Don Zickus wrote:
> > - A single client where I can do all my review. With web-based UIs for
> >   forges, you have to log in every forge for every project you work on.
> >   That's one for github, one for gitlab, one for each self-hosted github
> >   or gitlab instance (fd.o has a self-hosted public gitlab instance,
> >   it's also common for large companies to have self-hosted private
> >   instances), and I'm not counting gerrit instances or other forges.
> >   It's painful, I want not only to get all the notifications in a single
> >   client (that's already possible with e-mail notifications) but handle
> >   review in a single client too.
> 
> The biggest hurdle for reviews I see is un-authenticated email sent to an
> autenticated forge. 

I'd be interested in exploring how this can be addressed. We can already do a
lot of it by relying on DKIM signatures, which should give you a significant
level of assurance that messages aren't forged (with caveats). If you create
the initial Message-Id with strong randomness on your end, then you could use
that together with the DKIM signature as a fairly reliable authentication
token. When receiving a follow-up message, you can check that:

1. the DKIM signature is valid
2. the References: header is included in signed headers (it almost always is)
3. the message-id in the References: field matches what you have on record

This should give you a pretty strong assurance that messages you receive are
valid and the From: field can be trusted.

Part of my end-to-end attestation work was to introduce the
X-Developer-Signature header that uses the DKIM standard with developers'
personal keys (https://pypi.org/project/patatt/). The biggest obstacle to
adoption with this scheme is making it possible to use it with regular mail
clients and not just git-send-email (especially the web clients), so I'm not
sure whether we can easily use this approach for more generic message
authentication.

-K