Re: Password identifiers, protocol aging and SCRAM protocol

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Valery Popov <v(dot)popov(at)postgrespro(dot)ru>
Subject: Re: Password identifiers, protocol aging and SCRAM protocol
Date: 2016-08-18 12:28:10
Message-ID: 69938195-9c76-8523-0af8-eb718ea5b36e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/22/2016 03:02 AM, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2016-08-18 12:29:17 Re: [Patch] New psql prompt substitution %r (m = master, r = replica)
Previous Message Michael Paquier 2016-08-18 11:35:40 Re: Anyone want to update our Windows timezone map?