Re: Password identifiers, protocol aging and SCRAM protocol - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Password identifiers, protocol aging and SCRAM protocol
Date
Msg-id 79774ac1-df34-6b20-1659-c020c3842ce1@iki.fi
Whole thread Raw
In response to Re: Password identifiers, protocol aging and SCRAM protocol  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Password identifiers, protocol aging and SCRAM protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: Password identifiers, protocol aging and SCRAM protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On 09/26/2016 09:02 AM, Michael Paquier wrote:
>> * [PATCH 2/8] Move encoding routines to src/common/
>> >
>> > I wonder if it is confusing to have two of encode.h/encode.c.  Perhaps
>> > they should be renamed to make them distinct?
> Yes it may be a good idea to rename that, like encode_utils.[c|h] for
> the new files.

Looking at these encoding functions, the SCRAM protocol actually uses 
base64 for everything. The hex encoding is only used in the server, to 
encode the StoredKey and ServerKey in pg_authid. So we don't need that 
in the client. It would actually make sense to use base64 for the fields 
in pg_authid, too. Takes less space, and seems more natural for SCRAM 
anyway.

libpq actually has its own implementation of hex encoding and decoding 
already, in fe-exec.c. So if we wanted to use hex-encoding for 
something, we could use that, or if we moved the routines from 
src/backend/utils/encode.c, then we should try to reuse them for the 
purposes of fe-exec.c, too. And libpq already has an implementation of 
the 'escape' encoding, too, in fe-exec.c.  But as I said above, I don't 
think we need to touch any of that.

In summary, I think we only need to move the base64 routines to 
src/common. I'd prefer to be quite surgical in what we put in 
src/common, and avoid moving stuff that's not strictly required by both 
the server and the client.

- Heikki




pgsql-hackers by date:

Previous
From: valeriof
Date:
Subject: Transaction user id through logical decoding
Next
From: Heikki Linnakangas
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol