Bill Moran wrote:
> Not to start an argument, but you could reverse that logic and say "Do you want
> to hurt the smart, ssl users by not including helpful functionality that could
> be dangerous to uneducated non-ssl users?"
>
> IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm
> familiar with the strong push for stability, and I approve. But I'm not as
> sure I have a feel for what developers think about this kind of thing.
>
> If you made it a compile-time option, or made it disabled by default and
> requires a special setting in postgresql.conf to enable. Would that be secure?
> Not really, as stupid users would still enable it without understanding, and
> there's always the possibility that a some packager would build it with
> dangerous settings and distribute it widely.
>
> (As a side note, I seem to remember a program that had a --shoot-my-own-foot
> option to ./configure ... but I can't remember what it was ...)
>
> So, the question becomes one of design philosophy (at least, I'm basing this on
> the concept that actual implementation would not be too hard, correct me if I'm
> wrong)
You are correct. The question is whether it is worth adding that level
of complexity into the system --- in the past, we have decided it isn't.
We have the $HOME/.pgpass file to store username/password combinations
that is probably best, though it works only with libpq-based interfaces.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
