From: | Jorge Solórzano <jorsol(at)gmail(dot)com> |
---|---|
To: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: SCRAM client vs pgjdbc packaging |
Date: | 2017-07-13 15:06:14 |
Message-ID: | CA+cVU8O5FLJszj2AHAG-Lv+x+hnZSt+CKBtRdLz4jqzRakwbwA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
I vote for #2, with the maven-shade-plugin it should be easy to have an
uber-jar.
Jorge Solórzano
On Thu, Jul 13, 2017 at 5:14 AM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:
> Hello,
>
> Álvaro has implemented SCRAM support for pgjdbc (see https://github.com/
> pgjdbc/pgjdbc/pull/842 ), and it would be great to merge that.
>
> However, there might be a packaging issue.
>
> Technically speaking, the client is implemented in
> https://github.com/ongres/scram (BSD 2-clause "Simplified" License).
>
> I expect SCRAM to become the main way to authenticate, so it would be nice
> if pgjdbc could just work with no need to add different jars to the
> classpath.
>
> The question is how should we deal with the dependency.
>
> 1) We could make it optional & dynamic. That is we refrain from including
> the client to pgjdbc artifacts. In case backend is configured for SASL,
> pgjdbc would bail out with "please add scram-client-whatever.jar to the
> classpath" error.
> The drawback is pgjdbc would require a certain versions of scram-client,
> so it might cause troubles in future if application code and pgjdbc would
> require different incompatible versions of the client.
>
> 2) We could incorporate scram-client to the pgjdbc artifacts, so it would
> just work if backend requests SASL. This option enables us to repackage the
> client with our own name (e.g. org.postgresql.ongress.scram...), so it
> will enable applications to use scram-clients of their choice.
>
> I'm inclined to #2 (incorporate scram-client at build time), however I am
> not sure if it will ripple via some packaging issues.
>
> Note: I expect we might want to add new dependencies later (e.g. for "SASL
> string preparation", or Netty for networking layer), so it would be nice to
> know limits/edge packaging cases.
>
> Vladimir
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2017-07-13 18:58:41 | Re: SCRAM client vs pgjdbc packaging |
Previous Message | Vladimir Sitnikov | 2017-07-13 11:14:18 | SCRAM client vs pgjdbc packaging |