Re: Postgres 11 release notes - Mailing list pgsql-hackers

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@momjian.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 +