some PostgreSQL 12 release notes comments

On 9/17/19 1:09 PM, Peter Eisentraut wrote:

* Client- and server-side encryption for authentication using GSSAPI

This is on the wire encryption, so I don't know why it says client-side
and server-side. Proposal:

* Encrypted TCP/IP connections using GSSAPI encryption

+1, though I would s/GSSAPI encryption/ with s/GSSAPI authentcation/

in the major features section, and later

* Add GSSAPI encryption support (Robbie Harwood, Stephen Frost)

Perhaps "* Add encrypted connection support for GSSAPI authentication
(Robbie Harwood, Stephen Frost)"

This allows TCP/IP connections to be encrypted when using GSSAPI
authentication without having to set up a separate encryption facility
like SSL.

+1.

* Discovery of LDAP servers if PostgreSQL is built with OpenLDAP

I would remove the "if" part from the major features list, since it's a
qualification of minor importance. Instead I'd write something like

* Discovery of LDAP servers using DNS SRV

which is a clearer concept that people can easily recognize.

I agree it's clearer, I'm not sure if the OpenLDAP semantic above
changes things? I'm not sure the relative frequency of PostgreSQL being
built with OpenLDAP vs. other LDAP libs.

Regardless, I do like your change and would +1 it.

Would you like me to make a patch for it or are you planning to?

* Allow data type name to use non-C collations

I'm not sure why that is listed in the "Migration" section.

It's also a bit confusing as a release note item relative to PostgreSQL
11. I believe the changes were that "name" was made collation aware and
that the collation was set to "C" in the system catalogs (which is a
separate item later). This group of items could use a reshuffling.

I can't make an informed opinion on this one, so I defer to the experts.

Thanks!

Jonathan

On 2019-09-17 21:55, Jonathan S. Katz wrote:

* Encrypted TCP/IP connections using GSSAPI encryption

+1, though I would s/GSSAPI encryption/ with s/GSSAPI authentcation/

But you're not encrypting the communication using GSSAPI authentication,
you're encrypting it using GSSAPI encryption.

* Discovery of LDAP servers if PostgreSQL is built with OpenLDAP

I would remove the "if" part from the major features list, since it's a
qualification of minor importance. Instead I'd write something like

* Discovery of LDAP servers using DNS SRV

which is a clearer concept that people can easily recognize.

I agree it's clearer, I'm not sure if the OpenLDAP semantic above
changes things? I'm not sure the relative frequency of PostgreSQL being
built with OpenLDAP vs. other LDAP libs.

I suppose it's not-Windows vs. Windows.

It's OK if we mention OpenLDAP in the release notes, but it doesn't seem
to belong in the major features section.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

* Add GSSAPI encryption support (Robbie Harwood, Stephen Frost)

This allows TCP/IP connections to be encrypted when using GSSAPI
authentication without having to set up a separate encryption facility
like SSL.

Hmm, does that imply that you don't have to have compiled --with-openssl,
or just that you don't have to bother with setting up SSL certificates?
But you already don't have to do the latter. I'd be the first to admit
that I know nothing about GSSAPI, but this text still doesn't enlighten
me about why I should learn.

* Discovery of LDAP servers if PostgreSQL is built with OpenLDAP

I would remove the "if" part from the major features list, since it's a
qualification of minor importance.

OK

* Allow data type name to use non-C collations

I'm not sure why that is listed in the "Migration" section.

I think Bruce was reacting to this comment in the commit log for
478cacb50:

Prior to v12, if you used a collation-sensitive regex feature in a
pattern handled by processSQLNamePattern() (for instance, \d '\\w+'
in psql), the behavior you got matched the database's default collation.
Since commit 586b98fdf you'd usually get C-collation behavior, because
the catalog "name"-type columns are now marked as COLLATE "C". Add
explicit COLLATE specifications to restore the prior behavior.

(Note for whoever writes the v12 release notes: the need for this shows
that while 586b98fdf preserved pre-v12 behavior of "name" columns for
simple comparison operators, it changed the behavior of regex operators
on those columns. Although this patch fixes it for pattern matches
generated by our own tools, user-written queries will still be affected.
So we'd better mention this issue as a compatibility item.)

The existing text for this item doesn't make that aspect clear
enough, perhaps.

regards, tom lane

On 9/17/19 4:10 PM, Peter Eisentraut wrote:

On 2019-09-17 21:55, Jonathan S. Katz wrote:

* Encrypted TCP/IP connections using GSSAPI encryption

+1, though I would s/GSSAPI encryption/ with s/GSSAPI authentcation/

But you're not encrypting the communication using GSSAPI authentication,
you're encrypting it using GSSAPI encryption.

Ah, I also did a s/using/for/ in my head, but that's still not correct.
+1 to your suggested wording with no alterations.

* Discovery of LDAP servers if PostgreSQL is built with OpenLDAP

I would remove the "if" part from the major features list, since it's a
qualification of minor importance. Instead I'd write something like

* Discovery of LDAP servers using DNS SRV

which is a clearer concept that people can easily recognize.

I agree it's clearer, I'm not sure if the OpenLDAP semantic above
changes things? I'm not sure the relative frequency of PostgreSQL being
built with OpenLDAP vs. other LDAP libs.

I suppose it's not-Windows vs. Windows.

It's OK if we mention OpenLDAP in the release notes, but it doesn't seem
to belong in the major features section.

Well, if you're a Windows user, you may then be disappointed later on to
find out it does not work :)

That said, I'm ok with the more concise wording.

Jonathan

On 2019-09-17 22:22, Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

* Add GSSAPI encryption support (Robbie Harwood, Stephen Frost)
This allows TCP/IP connections to be encrypted when using GSSAPI
authentication without having to set up a separate encryption facility
like SSL.

Hmm, does that imply that you don't have to have compiled --with-openssl,
or just that you don't have to bother with setting up SSL certificates?
But you already don't have to do the latter. I'd be the first to admit
that I know nothing about GSSAPI, but this text still doesn't enlighten
me about why I should learn.

It means, more or less, if you already have the client and the server do
the GSS dance for authentication, you just have to turn on an additional
flag and they'll also encrypt the communication while they're at it.

This does not require SSL support.

So if you already have a Kerberos infrastructure set up, you can get
wire encryption for almost free without having to set up a parallel SSL
CA infrastructure. Which is great for administration.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Sep 17, 2019 at 7:09 PM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

* Discovery of LDAP servers if PostgreSQL is built with OpenLDAP

I would remove the "if" part from the major features list, since it's a
qualification of minor importance. Instead I'd write something like

* Discovery of LDAP servers using DNS SRV

-> "DNS SRV records" I think?

which is a clearer concept that people can easily recognize.

+1. The "discovery" part isn't actually part of LDAP, it's part of DNS, so
leaving that part out does a disservice.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

I've pushed some release note adjustments responding to your points
about the GSSAPI and name-collation entries. I see the LDAP text
is fixed already.

regards, tom lane

Greetings,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:

On 2019-09-17 22:22, Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

* Add GSSAPI encryption support (Robbie Harwood, Stephen Frost)
This allows TCP/IP connections to be encrypted when using GSSAPI
authentication without having to set up a separate encryption facility
like SSL.

Hmm, does that imply that you don't have to have compiled --with-openssl,
or just that you don't have to bother with setting up SSL certificates?
But you already don't have to do the latter. I'd be the first to admit
that I know nothing about GSSAPI, but this text still doesn't enlighten
me about why I should learn.

It means, more or less, if you already have the client and the server do
the GSS dance for authentication, you just have to turn on an additional
flag and they'll also encrypt the communication while they're at it.

This does not require SSL support.

So if you already have a Kerberos infrastructure set up, you can get
wire encryption for almost free without having to set up a parallel SSL
CA infrastructure. Which is great for administration.

Right- and more-over, you *do* get mutual authentication between the
client and the server when using Kerberos. This is markedly better than
"TLS/SSL with snakeoil certs, just to get encryption"- it's just about
equivilant to a full PKI environment with client and server validation
and encryption, but without needing openssl or SSL of any kind.

Thanks,

Stephen