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. -----Original Message----- From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: maandag 8 juni 2009 10:41 To: Brandon S. Allbery KF8NH Cc: Niemeijer, R.A.; haskell-cafe@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 time. Nevertheless: (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 days...). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH