Re: Where should i contact right people in CakePHP.org because this security critical problem

i always do it the other way around
in core debug=0 and if on localhost, raise it afterwards to 1/2
this way there should be no flaws

On 23 Jun., 06:50, oceanguy <seagri...@gmail.com> wrote:
> I've been baking for over 3 years, and while I know leaving debug >0
> is not kosher, I often leave it temporarily at 1 for quasi-production
> sites, as it is a heck of a lot easier to debug run-time issues.
>
> But I had no idea that database info would ever be exposed.  And why
> would I?  Seems like only a peculiar set of circumstances would have
> lead me to this error.  If there's one piece of config information
> that shouldn't be exposed at all by an application, it's the db
> connection info.  (Salt keys are probably a close second.)
>
> If something is a bad practice, then it's up to the community to find
> the best way to inhibit it automatically.  It's really a question of
> the community's integrity as a whole.  If it's common for end user
> developers to make a mistake, then that speaks to an issue that needs
> to be addressed at the core level, otherwise everyone's reputation
> suffers.
>
> CakePHP is a complex application and there is *a lot* to learn about
> it.  Verbal notes hidden in forums (or even the docs) won't cut it,
> nor will saying, "if you followed best practice X, you wouldn't have
> exposed yourself to Y."  End user developers do not know the details
> of how things might work under all circumstances, so we must trust the
> core developers to insure that best practices are in place to protect
> us from ourselves.
>
> If it's a question of encouraging developers to maintain separate
> core.php files on dev and production machines, I think an alternative
> distribution model might be helpful.  For example, maybe core.php
> should be distributed like database.php.default, which encourages devs
> to make a specific customized copy for each machine, which also
> implies not including it under version control.
>
> Aside from this quibble, thanks for an awesome framework (and Mark,
> for a great blog).
>
> -Sage
>
> On Jun 22, 1:02 pm, mark_story <mark.st...@gmail.com> wrote:
>
>
>
>
>
>
>
> > It is the developer's fault, for deploying a system in a way it should
> > never be deployed.
>
> > Since, I was working under the pre-tense that any developer who
> > actually cared about these kinds of things wouldn't make a stupid
> > mistake like this. And combined with the fact that removing the
> > passwords is a non-trivial problem, I punted on the issue.  The place
> > where this error gets displayed from is inside Debugger, and its more
> > than non-trivial to filter through the various parts of output,
> > looking for things that follow password, and cutting them out.  While
> > this is probably doable it will affect all the messages that Debugger
> > will create.
>
> > I guess I underestimated the ability of people to screw up basic
> > deployment.  If someone want's to prepare a patch, I'd be happy to
> > apply it so people who can't be bothered to properly deploy their
> > applications, can sleep better at night.
>
> > -Mark

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.

To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php