> Historically, Postgres lets you send credentials
> in plaintext and assumes you know what you're doing.
Yes, but if we look at the oauth part:
* It requires OAUTHDEBUG=UNSAFE to use http instead of https to get
the token. The documentation makes it clear that this option is unsafe
because it transmits authentication data in clear-text
* We also want to add a reminder to the unsafe trace output that warns
users that the trace contains sensitive authentication data, do not
share it with others
* But then if the configuration specifies a plaintext connection to
postgres, it silently accepts and uses it. It isn't mentioned anywhere
that this is a bad idea.
Another thing is that users usually aren't aware that oauthbearer
requires TLS, and just trust the implementation. SCRAM doesn't have
this requirement, so we can't even say something like "use TLS with
SASL", it depends on the mechanism.
> We would still need to consider compatibility, though. I keep hearing
> people talk about running infrastructure within "trusted" TCP (I
> assume via a mesh or cloud VPN of some sort?) and I don't know that
> they should be made to use a debug flag.
Is this a common-enough use case to think about? Even within a
"trusted" infrastructure, sending passwords in cleartext seems wrong
to me.
I used OAUTHDEBUG because I wanted to keep backward compatibility (but
my main reasoning was easier testing, not actual production use), and
it was an already existing environment variable also used by the
http/https switch. I didn't want to introduce a new environment
variable for this purpose, and I also didn't want to introduce a new
connection option.
As an alternative idea, what do you think about requiring an
explicitly specified sslmode=disable in the connection string? That
would also fit into the error message of my current patch, we could
even modify it to "consider sslmode=require or specify sslmode=disable
to override"
> One big alternative I can think of: I plan to push on file-based libpq
> configuration
That would definitely be a better fit, but I was hoping this could be
fixed even in earlier branches, as this can be potentially dangerous.
However, given the compatibility concern that seems unlikely.
> We should allow gssenc, yeah, unless you know of a reason that
> gssenc+OAuth doesn't work today? (If it doesn't, that's unintentional
> and I need to look into it.)
No, I only left it out from it because the RFC explicitly requires
TLS. v2 also permits gss.
> IMO, yes (especially if the client default were to change). In fact we
> could consider adding that regardless of whether the client side
> change gets committed.
Also attached 0002, which adds the server side warning.
