Re: Postgres 11 release notes

On Sun, May 13, 2018 at 03:43:08PM +0900, Michael Paquier wrote:
> On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote:
> > I have committed the first draft of the Postgres 11 release notes. I
> > will add more markup soon. You can view the most current version
> > here:
>
> Thanks for gathering all the commits in one piece, Bruce.
>
> > I expect a torrent of feedback. ;-)
>
> I looked at the entries where my name shows up. Here is some feedback
> with HEAD at 8c6227a2 (latest as of writing this message).
>
> <para>
> Add information_schema columns related to table constraints and
> triggers (Michael Paquier)
> </para>
> The author of this entry is Peter Eisentraut, not me.

Thanks, I got "Reviewed-by" and "Author" mixed up.

> <para>
> Channel binding requires the server end
> of the <acronym>TLS</acronym> connection to
> prove that it knows the password. The options are <link
> linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>
> and <option>scram_channel_binding=tls-server-end-point</option>.
> </para>
> This is not actually correct. Channel binding is an MITM prevention
> mechanism which makes sure that after the SSL handshake the backend and
> the frontend are still connected to the same things. "tls-unique" makes
> sure that a connection is uniquely used using a hash of the TLS finish
> message, and end-point makes sure that the endpoints are the same using
> a hash of the server certificate.

So, channel binding has had me confused since I first heard about it. I
have done some research and reworded the commit with the attached first patch.

Also, I have created a second patch which actually explains the two
SCRAM channel binding options and how the work.

One question I do have is how do we prevent a fake server in the middle
from pretending it is a PG 10 server and therefore avoiding channel
binding protections? I don't see any channel binding options in
pg_hba.conf, and while libpq has options, they are explained with "This
parameter is mainly intended for protocol testing."

> <para>
> WHAT DOES THIS DOC TEXT MEAN? "An empty value specifies that
> the client will not use channel binding. The default value
> is tls-unique."
> </para>
> This means that the client can choose to not use channel binding (which
> sends a 'n' flag if you refer to the communication protocol of SCRAM),
> even if the server has advertised to the client channel binding. So
> this provides a way to disable the feature at will, an on/off switch if
> you want. If a v10 libpq tries to connect to a v11 server, then it
> won't use channel binding automatically. That may be worth adding to
> the documentation as well.

I have updated the docs in the second patch to explain this.

> <para>
> Allow access to file system functions to be controlled by
> <command>GRANT</command>/<command>REVOKE</command> permissions,
> rather than super-user checks (Michael Paquier)
> </para>
> Author is Stephen Frost here.

Done.

> <para>
> Use <command>GRANT</command>/<command>REVOKE</command>
> to control access to <link
> linkend="lo-import"><function>lo_import()</function></link>
> and <function>lo_export()</function> (Michael Paquier)
> </para>
> Tom Lane is a co-author here I think.

Done.

> <para>
> Add libpq parameter to allow physical and logical replication
> connections (Michael Paquier)
> </para>
> This commit has just added documentation which was missing and
> incomplete. I would suggest to remove it from the release notes as no
> new feature has been added.

Removed.

> <para>
> Add <link
> linkend="app-pgreceivewal"><application>pg_receivewal</application></link>
> option <option>--no-sync</option> to prevent synchronous
> <acronym>WAL</acronym> writes (Michael Paquier)
> </para>
> Perhaps this should be rewritten? --no-sync just disables any fsync
> calls for WAL segments, which is useful for tests, not recommended for
> production environments.

Done.

> <para>
> Prevent <application>pg_rewind</application> from running as
> <literal>root</literal> (Magnus Hagander)
> </para>
> This one's authorship is actually mine, after a bug I found :)

Done, thanks much.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +