Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Thu, Apr 29, 2021 at 7:08 AM Peter Eisentraut > <peter.eisentr...@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
signature.asc
Description: PGP signature