[Haskell-cafe] Slow documentation generation on Hackage

[Niemeijer, R.A.]

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 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  
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 at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH