Naming of gss_accept_deleg

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:

Why is the new PG 16 GUC called "gss_accept_deleg" and not
"gss_accept_delegation"? The abbreviation here seems atypical.

At the time it felt natural to me but I don't feel strongly about it,
happy to change it if folks would prefer it spelled out.

Thanks,

Stephen

On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:

Why is the new PG 16 GUC called "gss_accept_deleg" and not
"gss_accept_delegation"? The abbreviation here seems atypical.

At the time it felt natural to me but I don't feel strongly about it,
happy to change it if folks would prefer it spelled out.

Yes, please do spell it out, thanks. The fact "deleg" looks similar to
"debug" also doesn't help.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

At 2023-05-19 09:16:09 -0400, bruce@momjian.us wrote:

On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:

Why is the new PG 16 GUC called "gss_accept_deleg" and not
"gss_accept_delegation"? The abbreviation here seems atypical.

At the time it felt natural to me but I don't feel strongly about it,
happy to change it if folks would prefer it spelled out.

Yes, please do spell it out, thanks. The fact "deleg" looks similar to
"debug" also doesn't help.

Note that GSS-API itself calls it the "DELEG" flag:

if (conn->gcred != GSS_C_NO_CREDENTIAL)
gss_flags |= GSS_C_DELEG_FLAG;

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

-- Abhijit

Abhijit Menon-Sen <ams@toroid.org> writes:

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

+1 for spelling it out in all user-visible names. I do not think
that that GSS-API C symbol is a good precedent to follow.

regards, tom lane

On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:

Abhijit Menon-Sen <ams@toroid.org> writes:

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

+1 for spelling it out in all user-visible names. I do not think
that that GSS-API C symbol is a good precedent to follow.

Once nice bonus of the release notes is that it allows us to see the new
API in one place to check for consistency.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:

Abhijit Menon-Sen <ams@toroid.org> writes:

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

+1 for spelling it out in all user-visible names. I do not think
that that GSS-API C symbol is a good precedent to follow.

+1

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Fri, May 19, 2023 at 07:58:34AM -0700, Nathan Bossart wrote:

On Fri, May 19, 2023 at 09:42:00AM -0400, Tom Lane wrote:

Abhijit Menon-Sen <ams@toroid.org> writes:

I would also prefer a GUC named gss_accept_delegation, but the current
name matches the libpq gssdeleg connection parameter and the PGSSDELEG
environment variable. Maybe there's something to be said for keeping
those three things alike?

+1 for spelling it out in all user-visible names. I do not think
that that GSS-API C symbol is a good precedent to follow.

+1

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On Sat, May 20, 2023 at 08:17:57PM -0700, Nathan Bossart wrote:

On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

Yes, please do. I saw some matches in the tests but was confused since
my tests passed. I now realize I wasn't testing those.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

Nathan Bossart <nathandbossart@gmail.com> writes:

On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

regards, tom lane

On Sat, May 20, 2023 at 11:21:57PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

Oh, I didn't consider those. I thought we would leave libpq alone since
those are often supplied on the command line and there are existing
short-style libpq options, e.g., gssencmode, krbsrvname, sslcrl.

I am fine with such a change though.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

On Sat, May 20, 2023 at 11:21:57PM -0400, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

Done.

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

Please do.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

At 2023-05-20 23:21:57 -0400, tgl@sss.pgh.pa.us wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:

With less then 48 hours to beta 1 packaging, I have made this change and
adjusted internal variable to match.

The buildfarm and cfbot seem unhappy with 9c0a0e2. It looks like there are
a few remaining uses of gss_accept_deleg to rename. I'm planning to commit
the attached patch shortly.

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

I was trying the change to see if it would be better to name it
"gssdelegate" instead (as in delegate on one side, and accept the
delegation on the other), but decided that "gssdelegation=enable"
reads better than "gssdelegate=enable".

Here's the diff.

-- Abhijit

Abhijit Menon-Sen <ams@toroid.org> writes:

At 2023-05-20 23:21:57 -0400, tgl@sss.pgh.pa.us wrote:

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

I was trying the change to see if it would be better to name it
"gssdelegate" instead (as in delegate on one side, and accept the
delegation on the other), but decided that "gssdelegation=enable"
reads better than "gssdelegate=enable".

Yeah, agreed.

Here's the diff.

Thanks for doing that legwork! I found a couple other places where
"deleg" had escaped notice, and changed the lot. Watching the
buildfarm now ...

regards, tom lane

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Abhijit Menon-Sen <ams@toroid.org> writes:

At 2023-05-20 23:21:57 -0400, tgl@sss.pgh.pa.us wrote:

I thought the plan was to also rename the libpq "gssdeleg" connection
parameter and so on? I can look into that tomorrow, if nobody beats
me to it.

I was trying the change to see if it would be better to name it
"gssdelegate" instead (as in delegate on one side, and accept the
delegation on the other), but decided that "gssdelegation=enable"
reads better than "gssdelegate=enable".

Yeah, agreed.

Here's the diff.

Thanks for doing that legwork! I found a couple other places where
"deleg" had escaped notice, and changed the lot. Watching the
buildfarm now ...

Thanks all for taking this up over a weekend.

Stephen

I noticed that the value that enables this feature at libpq client side
is 'enable'. However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.

Also, it looks like connectOptions2() doesn't validate the string value.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I noticed that the value that enables this feature at libpq client side
is 'enable'. However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.

Also, it looks like connectOptions2() doesn't validate the string value.

Hmm, it certainly seems like this ought to accept exactly the
same inputs as other libpq boolean settings. I can take a look
unless somebody else is already on it.

regards, tom lane

At 2023-05-22 09:42:44 -0400, tgl@sss.pgh.pa.us wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I noticed that the value that enables this feature at libpq client side
is 'enable'. However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.

Also, it looks like connectOptions2() doesn't validate the string value.

Hmm, it certainly seems like this ought to accept exactly the
same inputs as other libpq boolean settings. I can take a look
unless somebody else is already on it.

I'm working on it.

-- Abhijit

At 2023-05-22 09:42:44 -0400, tgl@sss.pgh.pa.us wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I noticed that the value that enables this feature at libpq client side
is 'enable'. However, for other Boolean settings like sslsni,
keepalives, requiressl, sslcompression, the value that enables feature
is '1' -- we use strings only for "enum" type of settings.

Also, it looks like connectOptions2() doesn't validate the string value.

Hmm, it certainly seems like this ought to accept exactly the
same inputs as other libpq boolean settings. I can take a look
unless somebody else is already on it.

Here's the diff, but the 0/1 values of settings like sslsni and
sslcompression don't seem to be validated anywhere, unlike the string
options in connectOptions2, so I didn't do anything for gssdelegation.

(I've never run the Kerberos tests before, but I changed one
"gssdelegation=disable" to "gssdelegation=1" and got a test failure, so
they're probably working as expected.)

-- Abhijit