You can clone with
A warning that this "could" happen really isn't sufficient, particularly when using this in conjunction with other Rack middleware like Rack::Session::Cookie will result in leakage of the session cookie secret.
For reference, here's how Django handles its debug page: https://github.com/django/django/blob/master/django/views/debug.py
Note the HIDDEN_SETTINGS variable and the use of cleanse_setting() to prevent configuration of Django built-ins from leaking.
To reproduce: enable ShowExceptions and Session::Cookie, then do anything to a Rack-powered application that causes it to crash and show the ShowExceptions page. Witness the dumping of all of env, including rack.session.options and its :secret/:oldsecret values.
Hosting things in development mode in production is generally a really bad idea regardless. I'll consider this either way, as users cannot be trusted with themselves, but this makes me uneasy. It's always an incomplete approach, and just as flawed as $SAFE - that is, whilst I can block things that live in rack, when someone adds non-core middleware, I can't protect them from themselves anymore. Only you can protect yourself.
How does the secret get into the env, anyway?
@raggi Agreed wholeheartedly, but "sane defaults" is also a good principle.
@chneukirchen I'm not that familiar with the Rack code but it looks like the middleware merges its options into the server options when it initializes. That might be how it gets there?
I wonder why it does that... it only verifies against the secrets stored in the instance variables...
@skimbrel the sane default exists here: https://github.com/rack/rack/blob/master/lib/rack/server.rb#L212-223
I'm closing this out for now. I'd accept a lightweight patch for this, but will not take the time to implement it at present. ShowExceptions is not recommended for production use.