Re: Password identifiers, protocol aging and SCRAM protocol

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael.paquier@gmail.com>
Cc: David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Julian Markwort <julian.markwort@uni-muenster.de>, Stephen Frost <sfrost@snowman.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Valery Popov <v.popov@postgrespro.ru>
Date: 2016-08-18T12:28:10Z
Lists: pgsql-hackers
On 07/22/2016 03:02 AM, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm confused.  We need that code in both libpq and backend, no?
>>> src/common is the place for stuff of that description.
>
>> Not necessarily. src/interfaces/libpq/Makefile uses a set of files
>> like md5.c which is located in the backend code and directly compiles
>> libpq.so with them, so one possibility would be to do the same for
>> sha.c: locate the file in src/backend/libpq/ and then fetch the file
>> directly when compiling libpq's shared library.
>
> Meh.  That seems like a hack left over from before we had src/common.
>
> Having said that, src/interfaces/libpq/ does have some special
> requirements, because it needs the code compiled with -fpic (on most
> hardware), which means it can't just use the client-side libpgcommon.a
> builds.  So maybe it's not worth improving this.

src/common/Makefile says:

> # This makefile generates two outputs:
> #
> #	libpgcommon.a - contains object files with FRONTEND defined,
> #		for use by client application and libraries
> #
> #	libpgcommon_srv.a - contains object files without FRONTEND defined,
> #		for use only by the backend binaries

It claims that libpcommon.a can be used by libraries, but without -fPIC, 
that's a lie.

>> One thing about my current set of patches is that I have begun adding
>> files from src/common/ to libpq's list of files. As that would be new
>> I am wondering if I should avoid doing so.
>
> Well, it could link source files from there just as easily as from the
> backend.  Not object files, though.

I think that's the way to go (and that's what Michael's latest patch 
did). But let's update the comment in the Makefile, explaining that you 
can also copy or symlink source files directly from src/common as 
needed, for instance for shared libraries.

Let's take the opportunity and also move src/backend/libpq/ip.c and 
md5.c into src/common. It would be weird to have sha.c in src/common, 
but md5.c in src/backend/libpq. Looking at ip.c, it could be split into 
two: some of the functions in ip.c are clearly not needed in the client, 
like enumerating all interfaces.

- Heikki



Commits

  1. Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).

  2. Refactor SHA2 functions and move them to src/common/.

  3. Replace isMD5() with a more future-proof way to check if pw is encrypted.

  4. Remove bogus notice that older clients might not work with MD5 passwords.

  5. Refactor the code for verifying user's password.

  6. Replace PostmasterRandom() with a stronger source, second attempt.

  7. Remove support for (insecure) crypt authentication.