weird libpq GSSAPI comment

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>
Subject: weird libpq GSSAPI comment
Date: 2019-12-24 15:15:20
Message-ID: 20191224151520.GA16435@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I found this comment in fe-connect.c:

/*
* If GSSAPI is enabled and we have a credential cache, try to
* set it up before sending startup messages. If it's already
* operating, don't try SSL and instead just build the startup
* packet.
*/

I'm not sure I understand this correctly. Why does it say "just build
the startup" packet about the SSL thing, when in reality the SSL block
below is unrelated to the GSS logic? If I consider that SSL is just a
typo for GSS, then the comment doesn't seem to describe the logic
either, because what it does is go to CONNECTION_GSS_STARTUP state which
*doesn't* "build the startup packet" in the sense of pqBuildStartupPacket2/3,
but instead it just does pqPacketSend (which is what the SSL block below
calls "request SSL instead of sending the startup packet").

Also, it says "... and we have a credential cache, try to set it up..." but I
think it should say "if we *don't* have a credential cache".

Now that I've read this code half a dozen times, I think I'm starting to
vaguely understand how it works, but I would have expected the comment
to explain it so that I didn't have to do that.

Can we discuss a better wording for this comment? I wrote this, but I
don't think it captures all the nuances in this code:

/*
* If GSSAPI is enabled, we need a credential cache; we may
* already have it, or set it up if not. Then, if we don't
* have a GSS context, request it and switch to
* CONNECTION_GSS_STARTUP to wait for the response.
*
* Fail altogether if GSS is required but cannot be had.
*/

Thanks!

--
Álvaro Herrera http://www.twitter.com/alvherre

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-24 16:08:29 Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence
Previous Message Fabien COELHO 2019-12-24 13:22:22 Re: Should we rename amapi.h and amapi.c?