Re: RFC: individual public-inbox/git activity feeds

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Fri, 11 Oct 2019 15:39:00 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:

> On Fri, Oct 11, 2019 at 07:15:12PM +0200, Dmitry Vyukov wrote:

> >This may also need some form of DoS protection (esp as we move further
> >from email).  
> 
> Well, amusingly, there are ways of distributing git via decentralized 
> protocols (SSB, DAT, IPFS). They are all fairly immature, though, and 
> some of them are truly terrible ideas.
> 
> For the moment, our best protection against DoS attacks on git repos is 
> having many frontends, some powerful allies (e.g. see 
> kernel.googlesource.com), and DoS-avoidance by obscurity ("I can't push 
> to kernel.org right now, but you can pull my repo from my personal 
> server over here").

The way I see, some spammer could send git pushes to the public-inbox
with thousands of SPAM, with would be forever stored at the repository.

So, if we're willing to implement it, we should have already a
solution for it since the beginning.

The only solution that sounds viable for me is to have a pre-receive
hook at the git server that would be receiving the commits.

Such hook would be customizable via .git/config, enabling or disabling
the functionalities and setting the thresholds:

1) prevent commits with too many patches;

If the push have more than, let's say, 20 patches, it would
reject the PR.  Doing that should be easy.

2) prevent commits from the same person if a certain threshold of
patches per period of time exceeds.

For example, no single developer (except maybe for the inbox owner) 
should be allowed to send more than, let's say, 1000 messages per day.

3) Implement gray lists

That would be more complex, but I guess it would be possible to implement
a hook that, for example, would check if the push comes from a known 
person (with signed patches with known keys) and/or a know IP address.

If not, it would push the contents on a separate gray list repository,
rejecting the change at the main one, and adding a notice for the
maintainer when a new person is added to the gray list.

If the owner of the public-inbox decides to accept the patch, it will
simply merge the gray list for that committer at the main inbox, and
the developer will be accepted as someone to trust.

4) Implement black list

If a previously trusted developer starts spamming or badly behaving,
he would be added to a black list file. Anyone there will have any
pull requests silently discarded.


Thanks,
Mauro