Robert Haas wrote:
> I frankly find that a bit difficult to swallow. You think that
> everyone knows that bad passwords are a problem, but some people might
> not realize that an authentication method called "trust" might not be
> secure?
Ultimately, what we offer to users is choice of a few options. Should
we only offer options that we consider to be completely secure, and no
others? If we were to follow that principle, we would completely
disable non-SSL builds, and all auth methods other than, I dunno, GSSAPI
and such. But we don't do that, because we trust that users will use
whatever is most appropriate for them. I see this patch is, in a way, a
mechanism to let system administrators choose at compile time what
options are available to DBAs at setup time. This seems a reasonable
thing to me.
I don't necessarily agree with the patch as proposed. I would rather
have a comma-separated list of methods, as in:
--disable-auth=ident,peer
which lets you choose what to disable without hardcoded choices. Due to
the nature of autoconf, this might be too fiddly to implement, though,
and if so I think the method proposed by this patch seems a reasonable
compromise. I've seen configure in other programs offer options such as
--disable-foo=list that lists acceptable values (or --disable-foo=help)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
