[Haskell-cafe] Slow documentation generation on Hackage
r.a.niemeijer at tue.nl
Mon Jun 8 05:05:59 EDT 2009
If that is the main concern, would the following not work?
- Hackage accounts already have to be created manually, so there is no
chance of a DDoS.
- Uploading to hackage requires a username and password, which means
the user can be identified. Set a timeout on uploads for each user:
packages sent within 2 minutes of the previous one are automatically
refused. Prevents quantity-based DoS.
- Generate haddock docs immediately on upload, but apply a 2-second
timeout; if it takes longer, the process is killed and no documentation
is generated. Prevents exploit-based DoS.
- If many valid packages are uploaded in a short time (though I have my
doubts as to how often that is going to happen), put them in a queue.
Documentation will take a bit longer to generate, but the server can
control the load. Prevents inadvertent DoS.
Result: immediate documentation for every contributor with good
intentions (which, face it, is going to be all of them; I doubt Haskell
is popular enough yet to be the target of DoS attacks) and no
possibility for DoS attacks. I might be overlooking something, but
I believe this should work just fine.
From: Brandon S. Allbery KF8NH [mailto:allbery at ece.cmu.edu]
Sent: maandag 8 juni 2009 10:41
To: Brandon S. Allbery KF8NH
Cc: Niemeijer, R.A.; haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Slow documentation generation on Hackage
On Jun 8, 2009, at 04:36 , Brandon S. Allbery KF8NH wrote:
> On Jun 8, 2009, at 04:10 , Niemeijer, R.A. wrote:
>> Hence I wanted to ask if this is a bug or if there is a good
>> technical or social reason for it, and whether there is any way
>> around it.
> Auto-running haddock on upload strikes me as a good way to open
> hackage.haskell.org to a denial of service attack.
I should clarify: yes, in a valid project haddock takes almost no
(1) if many uploads of even valid packages are made in a very short
time, the system load could well be severely impacted;
(2) what of malicious packages, which might trigger bugs in haddock
leading to (say) 100% CPU loops? That we don't know of any doesn't
mean there aren't any, unless the test suite is absolutely 100%
complete (and for a large program, that becomes as hard to verify as
the program itself. now consider that haddock is part of ghc these
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH
More information about the Haskell-Cafe