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
-
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
- 818fd4a67d61 10.0 landed
-
Refactor SHA2 functions and move them to src/common/.
- 273c458a2b3a 10.0 landed
-
Replace isMD5() with a more future-proof way to check if pw is encrypted.
- dbd69118c05d 10.0 landed
-
Remove bogus notice that older clients might not work with MD5 passwords.
- 7e3ae5455948 9.2.20 landed
- 470af1f41c8b 9.3.16 landed
- ada2cdb61015 9.4.11 landed
- 65a7f190b253 9.5.6 landed
- 7546c135dc30 9.6.2 landed
- 31c54096a18f 10.0 landed
-
Refactor the code for verifying user's password.
- e7f051b8f9a6 10.0 landed
-
Replace PostmasterRandom() with a stronger source, second attempt.
- fe0a0b5993df 10.0 landed
-
Remove support for (insecure) crypt authentication.
- 53a5026b5cb3 8.4.0 cited