We should consider changing darcs.cabal to detect for GHC 6.14 (and newer) and ensure 
that we enable RTS options when building.

See these two articles for details about the change to GHC:

http://www.amateurtopologist.com/2010/04/23/security-vulnerability-in-haskell-with-cgi/

http://hackage.haskell.org/trac/ghc/ticket/3910

RTS options are useful for:
  * profiling options
  * HPC options
  * debugging: answering questions "+RTS --info", toggling gc options, etc

If we disable it by default we should make sure none of our scripts and tools depend on 
RTS arguments, such as darcs-benchmark.

I think we shouldn't change it, because darcs may sometimes run in 
contexts where it has elevated privileges relative to the user causing 
it to be invoked. For example, a restricted ssh environment for darcs 
push.

I also understand (from Igloo) that +RTS --info will continue to work 
even when +RTS is turned off by default.

To be clear, I'm only against changing the default. I'd be happy with a 
cabal flag that enabled it.

Bumping to the next release as this isn't urgent enough for 2.5 (but
maybe 2.5.1? we could bump back down)

I think darcs-benchmark needs this, for what it's worth.

Eric Kow <bugs@darcs.net> writes:
> Bumping to the next release as this isn't urgent enough for 2.5 (but
> maybe 2.5.1? we could bump back down)
>
> I think darcs-benchmark needs this, for what it's worth.
Yes, we use it to collect memory use statistics. We may need to find a
different way to do that if the +RTS flag disappears by default...

Yours,
   Petr.

PS: I don't think the RTS flag is dangerous in the context of darcs. If
you can pass arbitrary parameters to darcs, you could already darcs get
dangerous things from the internet to locations darcs has write access
to (and with creative use --umask, --set-scripts-executable and
--posthook you could probably get to execute them as well). Writing some
sort of profiler stuff into these same locations sounds fairly less
dangerous (although you probably can't get darcs without +RTS to clobber
files as easily).

Perhaps I don't understand the milestones.  I would have thought that 
"2.5.0 CURRENT" means 2.5.x and that "2.6.0 HEAD" means the branch that 
becomes 2.6.0 BEFORE the 2.6.0 release branch is created.

Please consider this change to appear at least in the last release of darcs 
BEFORE ghc 6.14 is released.  Even if that only means providing the an 
option in the .cabal file to build with RTS options, regardless of the 
default for the flag.  So, if 6.14 is scheduled between 2.5.0 and 2.6.0, 
then please add this change before the 2.6.0 release.

Ideally, I think this should be enabled by default.  At Petr points out, 
there are much easier ways to wreak havoc with darcs than the rts exploit.  
So my vote is for the default to be true.

Discussion on milestones:
* http://lists.osuosl.org/pipermail/darcs-users/2010-August/024753.html

I'm leaving it up to you Ganesh and Petr to establish a consensus on the 
path forward.  

I suggest somebody (Jason?) just implement the flag first so that we've 
at least covered the common ground that we all agree on. Then we can 
debate the defaults :-)

My basic view is that in theory it ought to be possible to make darcs 
secure (e.g. with config options) for use on a server with restricted 
access - even if that's not the case right now. So I view keeping the 
+RTS hole by default as a step in the wrong direction.

On the other hand, the server configuration is probably quite rare and 
it might be reasonable to expect people to rebuild darcs for it; so the 
convenience for other situations could well outweigh that.

So overall I think I'm (now) neutral on this.

It's not a regression since 2.5, so bumping to 2.10.

Just observing that this was implemented/resolved by:

patch d57afee3106baa359e431edd2397ccdec4bfa8c9
Author: bsrkaditya@gmail.com
Date:   Sun Aug 26 13:49:21 ART 2012
  * Add flag rts to cabal