Re: SCRAM inplementation

On 03/04/17 02:28, Michael Paquier wrote:
> On Mon, Apr 3, 2017 at 1:05 AM, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:
>> * Write both a client and server implementation. pgjdbc will only require
>> the former, of course, but having both will be great for testing.
> Doesn't JDBC require already a Postgres instance when testing? You
> could just rely on that.

Needless to say, it will be tested against Postgres 10. But since I
plan to develop it as a separate library external to pgjdbc, meant for
general purpose use, it will have both client and server
implementations. It has the added benefit of unit tests that do not have
external and non-Java dependencies (like PostgreSQL).

>
>> * Do so as an independent library, also as an independent repository on
>> Github. This will help its reuse and testing by independent projects. I
>> presume it will have at least three different artifacts, a scram-common,
>> scram-server and scram-client. Only the latter will be directly imported as
>> a direct dependency by pgjdbc.
>> * The implementation will *not* provide support for message sending and/or
>> serialization. Only message generation and parsing (after all, messages are
>> only strings, so it's easy). This is meant to be easily reused, but will of
>> course require some glue code on the pgjdbc side.
>> * Channel biding will not be on the first version. It is not used in
>> PostgreSQL 10 either (as of today).
> Yep, this has been deferred for later versions. The protocol name with
> channel binding uses -PLUS as suffix, so that's no big deal from an
> implementation point of view to get that later on.

Right.

>
>> * Both SHA-1 and SHA-256 will be implemented (yeah, I know about SHA-1
>> collision, but it's still an RFC and adding it is a one-liner so... I leave
>> the decision to the users). PG 10 will only ship with SHA-256, though,
>> AFAIK.
> We are not going to ship with SCRAM-SHA-1 anyway, so I would advise to
> just have no trace of it.

Same as above: the idea is to have it as a general-purpose library.
Maybe others want SHA-1. It is very simple to implement it, it adds no
extra effort.

>
>> * First version will not implement SaslPrep (neither PG10 does). When it
>> will do.... I will probably do a separate repository for StringPrep/SaslPrep
>> code, as it is again of a very reusable nature outside of the SCRAM (and of
>> cours pgjdbc) projects.
> We'll see about that. I have a patch able to address the problem...

Please let me know any further info :)

Thanks,

Álvaro

--

Álvaro Hernández Tortosa

-----------
<8K>data