Stephen Frost <sfr...@snowman.net> writes: > * Robbie Harwood (rharw...@redhat.com) wrote: >> Stephen Frost <sfr...@snowman.net> writes: >>> * Robbie Harwood (rharw...@redhat.com) wrote: >>>> Stephen Frost <sfr...@snowman.net> writes: >>>>> * Robbie Harwood (rharw...@redhat.com) wrote: >>>>> >>>>>> Attached please find version 20 of the GSSAPI encryption support. >>>>>> This has been rebased onto master (thanks Stephen for calling out >>>>>> ab69ea9). >>>>> >>>>> I've looked over this again and have been playing with it >>>>> off-and-on for a while now. One thing I was actually looking at >>>>> implementing before we push to commit this was to have similar >>>>> information to what SSL provides on connection, specifically what >>>>> printSSLInfo() prints by way of cipher, bits, etc for the >>>>> client-side and then something like pg_stat_ssl for the server >>>>> side. >>>>> >>>>> I went ahead and added a printGSSENCInfo(), and then >>>>> PQgetgssSASLSSF(), which calls down into >>>>> gss_inquire_sec_context_by_oid() for GSS_C_SEC_CONTEXT_SASL_SSF to >>>>> get the bits (which also required including gssapi_ext.h), and now >>>>> have psql producing: >>>> >>>> While I (a krb5 developer) am fine with a hard MIT dependency, the >>>> project doesn't currently have this. (And if we went that road, >>>> I'd like to use gss_acquire_cred_from() instead of the setenv() in >>>> be-secure-gssapi.c.) >>> >>> We certainly don't want a hard MIT dependency, but if it's following >>> an RFC and we can gracefully fall-back if it isn't available then I >>> think it's acceptable. If there's a better approach which would >>> work with both MIT and Heimdal and ideally is defined through an >>> RFC, that'd be better, but I'm guessing there isn't... >> >> While I think the concept of SASL SSF is standardized, I don't think >> the semantics of this OID are - the OID itself is in the MIT gssapi >> extension space. > > We can adjust for that pretty easily, presumably, if another OID ends > up being assigned (though if one already exists, isn't it something > that Heimdal, for example, could potentially decide to just > support..?).
Yes, exactly - Heimdal would probably just use the MIT OID with the existing semantics. Thanks, --Robbie
signature.asc
Description: PGP signature
