|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, samay sharma <smilingsamay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: Proposal: Support custom authentication methods using hooks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2022-03-02 15:26:32 -0500, Stephen Frost wrote:
> Part of the point, for my part anyway, of dropping support for plaintext
> transmission would be to remove support for that from libpq, otherwise a
> compromised server could still potentially convince a client to provide
> a plaintext password be sent to it.
IMO that's an argument for an opt-in option to permit plaintext, not an
argument for removal of the code alltogether. Even that will need a long
transition time, because it's effectively a form of an ABI break. Upgrading
libpq will suddenly cause applications to stop working. So adding an opt-out
option to disable plaintext is the next step...
I don't think it makes sense to discuss this topic as part of this thread
really. It seems wholly independent of making authentication pluggable.
> I also just generally disagree with the idea that it makes sense for
> these things to be in contrib. We should be dropping them because
> they're insecure- moving them to contrib doesn't change the issue that
> we're distributing authentication solutions that send (either through an
> encrypted tunnel, or not, neither is good) that pass plaintext passwords
Shrug. I don't think it's a good idea to just leave people hanging without a
replacement. It's OK to make it a bit harder and require explicit
configuration, but dropping support for reasonable configurations IMO is
something we should be very hesitant doing.
|Next Message||Andres Freund||2022-03-02 21:17:59||Re: [Proposal] Global temporary tables|
|Previous Message||Justin Pryzby||2022-03-02 20:50:58||Re: Adding CI to our tree|