monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: GCC and Monotone


From: Zack Weinberg
Subject: Re: [Monotone-devel] Re: GCC and Monotone
Date: Tue, 02 Dec 2003 17:42:10 -0800
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

graydon hoare <address@hidden> writes:

> Zack Weinberg wrote:
>
>> One last issue: denial-of-service.  If we have the official depot
>> take patches by email from anyone (which I like, since it makes it
>> much harder to drop patches on the floor) then what's to stop someone
>> sending either a gargantuan patch, or a long series of small patches,
>> and filling up the disk?
>
> depots are probably a less-good fit for this than a public news server
> with no expiry. I'd like to flatter myself and say a depot will scale
> to hundreds of concurrent uploaders, but INN has a lot more practise
> in that category than a single-file-locking CGI I cooked up.

... I was using 'depot' as a generic term; I guess I meant 'database'?
The gcc.gnu.org server would probably handle NNTP, HTTP, and email;
and it's the last of these that I'm concerned about - access control
is easy to arrange for the first two, but we *want* arbitrary people
to be able to feed us patches via email.  They wouldn't get merged
until someone looks at them, but I think anonymous patch submission
into database has great promise for preventing patches from getting
dropped on the floor.

Spam filters would be very strict indeed (no packet? discard), and
an 16mb cap is good for stopping the more obvious sorts of abuse.

Other people are better than me at thinking of defenses for this sort
of thing.  Rate limiting seems like an obvious one though (it can even
go teergrube if it detects blatant abuse).

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]