On Mon, Apr 3, 2017 at 1:05 AM, Álvaro Hernández Tortosa <aht@8kdata.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.
> * 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.
> * 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.
> * 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...
--
Michael
