From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Jorge Solórzano <jorsol(at)gmail(dot)com> |
Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: SCRAM client vs pgjdbc packaging |
Date: | 2017-07-13 18:58:41 |
Message-ID: | CADK3HHJA368SMtR6OFSnXnWPRHkPpxgPeyrrQckJi2S5Ax6PWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
# 2 is my vote!
Dave Cramer
davec(at)postgresintl(dot)com
www.postgresintl.com
On 13 July 2017 at 18:06, Jorge Solórzano <jorsol(at)gmail(dot)com> wrote:
> 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 | Vladimir Sitnikov | 2017-07-14 08:30:49 | [pgjdbc/pgjdbc] 751455: fix: NPE in PreparedStatement.executeBatch in case... |
Previous Message | Jorge Solórzano | 2017-07-13 15:06:14 | Re: SCRAM client vs pgjdbc packaging |