Re: SCRAM client vs pgjdbc packaging

# 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
>>
>
>