On Thu, May 22, 2025 at 8:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm. That must be coming from this bit in libpq:
>
> /* Must have output.length > 0 */
> if (output.length > PQ_GSS_SEND_BUFFER_SIZE - sizeof(uint32))
> {
> pg_GSS_error(libpq_gettext("GSSAPI context establishment error"),
> conn, major, minor);
> gss_release_buffer(&minor, &output);
> return PGRES_POLLING_FAILED;
> }
>
> which makes it look like gss_init_sec_context wants us to send a
> packet larger than PQ_GSS_SEND_BUFFER_SIZE, which perhaps is a
> plausible thing to happen if the user belongs to enough groups.
Yeah, it seems like we need to be able to handle up to
PG_MAX_AUTH_TOKEN_LENGTH (64k) for that initial ticket, at least?
> * Therefore, these two #define's are effectively part of the protocol
> * spec and can't ever be changed.
> */
> #define PQ_GSS_SEND_BUFFER_SIZE 16384
> #define PQ_GSS_RECV_BUFFER_SIZE 16384
We can't increase our send buffer size without risking breakage, but a
peer could choose to receive larger initial packets without issue.
Then it comes down to deciding when to flip the sender into that
extended mode. Unfortunately this happens prior to feature
negotiation, and I don't see any obvious extension points yet. (Other
than introducing a completely new negotiation code, which would make
the existing fallback logic even worse than it is today.) Maybe the
user could just opt in for a few releases.
But also, the current behavior is just to fail hard, so if the client
tries to do something extra that also sometimes fails hard, it may not
really be a regression...
--Jacob
