Stephen Frost <sfrost@xxxxxxxxxxx> writes: > * Tom Lane (tgl@xxxxxxxxxxxxx) wrote: >> In the meantime, I did spot a code path that would explain the symptoms: >> pqsecure_open_gss() clears allow_ssl_try sooner than it oughta. If >> gss_wrap_size_limit() failed for some reason, we'd abandon the GSS >> connection and try another one, and we would *not* try to SSL-ify >> the new one. > There are certainly some very odd GSSAPI implementations out there > (including hacked up things particularly on Macs that we've seen..), > though I've not run into one where I've seen that call fail. The OP said he's on RHEL 8.3, so it ought to be mostly-stock Kerberos. I've just been digging through the SRPM to see if they'd done anything odd for FIPS mode or the like, and I'm not really finding anything. > If it did fail though, surely the error messages would make that > clear, and we're not seeing that here..? No, because we won't report the failure from gss_wrap_size_limit; we just discard that connection and try again. > I'm not sure how, but it sure seems like somehow, in this case, we're > going through the GSSAPI encryption code because we find GSSAPI > credentials (entirely possible, even if you're not using them for > talking to PG), the server responds with a "I haven't got support for > that" in some fashion, and we're skipping SSL at that point. How that's > happening isn't clear to me though, but the idea that it's because > gss_wrap_size_limit() is failing seems very unlikely. I already spent most of the day on theories like that, without any success. I agree that this theory seems quite unlikely, but you remember what Sherlock Holmes said. regards, tom lane
