Greetings,
* Magnus Hagander (magnus@hagander.net) wrote:
> On Thu, Apr 29, 2021 at 7:08 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
> > On 28.04.21 16:09, Alvaro Herrera wrote:
> > > Looking at it now, I wonder how well do the "hostno" options work. If I
> > > say "hostnogssenc", is an SSL-encrypted socket good? If I say
> > > "hostnossl", is a GSS-encrypted socket good? If so, how does that make
> > > sense?
> >
> > I think for example if you want to enforce SSL connections, then writing
> > "hostnossl ... reject" would be sensible. That would also reject
> > GSS-encrypted connections, but that would be what you want in that scenario.
>
> I'd say the interface has become a lot less well-matching now that we
> have two separate settings for it. For example right now it's more
> complex to say "reject anything not encrypted", which I bet is what a
> lot of people would want. They don't particularly care if it's gss
> encrypted or ssl encrypted.
I'm not really sure that I agree it's such an issue, particularly since
you have to come up with a way to specify the auth method to use somehow
too as we haven't got any fallback mechanism or anything like that.
While you might use cert-based auth or SCRAM for TLS connections, it
isn't the case that you can use SCRAM with a GSS encrypted connection.
> Perhaps what we want to do (obviously not for 14) is to allow you to
> specify more than one entry in the first column, so you could say
> "hostssl,hostgssenc" on the same row? That would give some strange
> results with the "no" mappings, but it might work if used right?
In general, I'm not against the idea of giving more options but I'm just
not sure that it's a real use-case when you consider that the auth
method also has to be specified. I also don't recall anyone showing up
asking about how they could specify "encrypted but I don't care how".
Thanks,
Stephen
