Re: thoughts on a Merge Request based development workflow

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Oct 15, 2019 at 09:15:27PM +0200, Han-Wen Nienhuys wrote:
>> As I see it, there are the following things that would make Gerrit a
>> difficult proposition:
>>
>> 1. A gerrit instance would introduce a single source of failure, which
>>    is something many see as undesirable. If there's a DoS attack, Google
>>    can restrict access to their Gerrit server to limit the requests to
>>    only come from their corporate IP ranges, but kernel.org cannot do
>>    the same, so anyone relying on gerrit.kernel.org cannot do any work
>>    while it is unavailable.
>
>I don't understand your scenario. Are you concerned that Google would
>protect DoS attacks by limiting traffic to the corp network?
>
>Or are you concerned that kernel.org has no DoS protection?

Kernel.org operates on a pretty small budget, largely using 
infrastructure donated by kind entities. If it suddenly becomes a 
liability, I'm sure those entities will kick us out. A large, sustained 
DoS attack would be one such liability, and due to the nature of git, we 
can't really hide behind cloudfront or any other DoS-mitigation
platforms.

If a DoS attack is waged against Google's gerrit server, they can drop 
the packets at the perimeter and still keep the service available to 
Google engineers coming from internally routed traffic. This is not an 
option for kernel.org, so a DoS attack against a central resource would 
be super effective in stopping all work on Linux.

>
>How does DoS protection for kernel.org work today? If someone DoSes
>git.kernel.org with its 1000s of git trees, how do people get work
>done?

The git trees on kernel.org are just convenient copies. Most kernel 
development is done via mailing patches, which is a distributed and 
DoS-resistant process. The only time git.kernel.org enters into the 
picture is when people need to send a pull request to Linus (via email).  
If kernel.org is out for an extended period of time, they would just 
push their repo elsewhere and send a pull request referencing the new 
URL. Since Linus checks PGP signatures when pulling remotes, the 
repository can be hosted anywhere at all without needing to trust the 
infrastructure.

With gerrit, if gerrit.kernel.org is down, then everything grinds to a 
halt. If it's down for an extended period of time, then in theory people 
can push their git trees elsewhere, but then they would have to 
force-push back to gerrit once it's back up.

>> 2. There is limited support for attestation with Gerrit. A change
>>    request can contain a digital signature, but any comments surrounding
>>    it do not. It would be easy for the administrator of the gerrit
>>    instance to forge a +1 or +2 on a CR making it look like it came from
>>    the maintainer or the CI service (in other words, we are back to
>>    explicitly trusting the infrastructure and IT admins).
>
>Does anyone use attestation/PGP signing for their code reviews that
>are conducted over Email? How many people use PGP signing on their
>commits?
>
>How does email figure into this story? Email has no authentication at
>all, so if this is a requirement, you should probably stop using email
>for reviews.

Well, it's one of the problems we are trying to solve! Linus verifies 
PGP signatures on all pull requests he receives that aren't coming from 
git.kernel.org (and I always complain to him that he shouldn't make an 
exception in our case either).

And we *are* trying to stop using email for reviews -- preferably 
without introducing single points of trust and single points of failure.  

>> 3. There is no email bridge, only notifications. Switching to gerrit
>>    would require a flag-day when everyone must start using it (or stop
>>    participating in kernel development).
>
>Gerrit sends out email for comments. If you reply to that email,
>Gerrit ingests the comment and puts it in the review.

Ah, okay, I guess we've never configured it that way. But you can't 
+1/+2/Merge anything using this mechanism, right? Otherwise that would 
be a backchannel around authentication. :)

-K