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

[Don Zickus <dzickus@redhat.com>]

On Mon, Jul 12, 2021 at 03:07:16PM -0400, Konstantin Ryabitsev wrote:
> 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

Happy to work towards a solution here.

> 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

GitLab provides that as a 'personal id', such that when you respond to

reply+<uuid str>@gitlab.com

it knows that uuid is unique to a user and allows the authentication.  So
there is something there to work with (for GitLab at least).

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

Hmm, I am not sure our approaches overlap.  You are focused on verifying
emailed patches can be trusted.  We are using 'git push ...' to accomplish
that.

Instead I was focused on how to establish a collaboration medium that
developers with non-gitlab accounts can participate in easily.  Basically if
we push patches using 'git push ...' and they get emailed out to a mailing
list, how can feedback emails find their way back into a gitlab service (or
other forges)?

Unless I misunderstood how far your patatt goes?

Cheers,
Don