New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SCRAM-SHA-256 support #842

Merged
merged 5 commits into from Nov 21, 2017

Conversation

Projects
None yet
8 participants
@ahachete
Contributor

ahachete commented Jun 11, 2017

PostgreSQL 10 comes with SCRAM-SHA-256 support. This commit introduces
support for it.

Work is based on an external dependency, the SCRAM client library:

https://github.com/ongres/scram/

which is now imported as a dependency.

TODO:
- SCRAM client library will be improved, on its own.
Particularily, StringPrep support needs to be added. Final
version of pgjdbc will depend on v1.0
- Testing
- Probably macros to avoid this Java8-only code propagating to
Java < 8 versions of the driver

@davecramer

This comment has been minimized.

Member

davecramer commented Jun 11, 2017

Looks like checkstyle is complaining quite a bit ;)

@davecramer

This comment has been minimized.

Member

davecramer commented Jun 13, 2017

I think you can use the jdk6,jdk7 profiles to exclude compilation of sasl/ScramAuthenticator.java then preprocessing to remove the import statements

public void processServerMechanismsAndInit() throws IOException, PSQLException {
String scramAuthenticationMechanism = pgStream.receiveString();
pgStream.receiveChar(); // '0' terminating the String

This comment has been minimized.

@sehrope

sehrope Jun 13, 2017

Contributor

This should assert that the zero byte is indeed a zero byte. At worst it's an extra "if" and, particularly in development, may catch protocol errors.

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

This is exactly what assertions are made for, so 100% agreed with an assertion. For development, developers should run with -ea ;)

public void processServerMechanismsAndInit() throws IOException, PSQLException {
String scramAuthenticationMechanism = pgStream.receiveString();
pgStream.receiveChar(); // '0' terminating the String
if (!EXPECTED_SERVER_ADVERTISED_METHODS.equals(scramAuthenticationMechanism)) {

This comment has been minimized.

@sehrope

sehrope Jun 13, 2017

Contributor

Currently the server only supports a single SCRAM auth mechanism but the protocol spec supports a list of values. This code will break if more than one auth mechanism is sent as the second and onward will not be read (and thus mess up whatever is next on the wire).

We'll need to keep reading strings until you get to one that is of length zero (i.e. the \0 all by itself) to indicate the end of the list. The strings themselves should be added to a list so that the priority order can be maintained.

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

Yes, you are right. I believe when I initially wrote this code, there was only one SCRAM mechanism defined, but after some discussion on -hackers it was turned into a list. Now changed to parse a list. Fortunately change is trivial, as the SCRAM library was already prepared to process a list of SCRAM mechanisms and pick "the best one" and throw IAE if bad things are passed to it :)

@@ -133,7 +138,8 @@ public QueryExecutor openConnectionImpl(HostSpec[] hostSpecs, String user, Strin
Iterator<HostSpec> hostIter = hostChooser.iterator();
while (hostIter.hasNext()) {
HostSpec hostSpec = hostIter.next();
LOGGER.log(Level.FINE, "Trying to establish a protocol version 3 connection to {0}", hostSpec);
LOGGER.log(Level.FINE, "Trying to establish a protocol version 3 connection to {0}",

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

Are those logging changes just formatting? Would you please refrain from introducing a feature and altering formats at the same time?

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

I did so because of the (strict) checkstyle requirements, which I only noticed after Travis run its job. I could resubmit the commits, squashing them, but I believe that is not what the history of the feature was, so I think it is more appropriate to leave it as is. Please let me know otherwise

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

I did so because of the (strict) checkstyle requirements, which I only noticed after Travis run its job.

What I mean is: there were no checkstyle violations before, and the line LOGGER.log(Level.FINE, "Trying to establish a protocol version 3 connection to {0}", hostSpec); was perfectly fine. I don't follow you on "noticed after Travis run its job".

Here's the log for your first commit: https://travis-ci.org/pgjdbc/pgjdbc/jobs/241824426
There are just "wrong import order", "unused import order", and "whitespace around -" warnings regarding ConnectionFactoryImpl.java. It did not warn on "wrong formatting of LOGGER.log calls".

So this particular change (and other changes to LOGGER.log kind of lines) seem to be unrelated to the PR itself.

PS. I do agree checkstyle warnings are not that human-friendly, however that helps us to keep codebase sane and uniform.

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

I'm not questioning checkstyle, I agree it's necessary to keep code sanity. I don't like current checkstyle, that's it, and its strictness (order of imports and lines separating imports, which cost me like 10 mins of trial and error since it was the first case with an external dependency import. was not productive work that helped code quality IMHO).

Having said that, all I did when I saw the checkstyle errors was let the IDE handle them. It might have been stricter than necessary doing it, but honestly, I don't want to invest more time into this. Current version is checkstyle compliant and, I would rather prefer to devote my effort towards more value in the code (like going through the TODOs of the SCRAM library, which still needs a lot of love). If anyone fixes this with another commit or I should squash the commits, I'd be happy to do so ;) but otherwise I would not use a lot of time on this ^_^

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

order of imports and lines separating imports, which cost me like 10 mins of trial and error since it was the first case with an external dependency import. was not productive work that helped code quality IMHO

There are ready to go IDEA/Eclipse configurations: https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md#support-for-ides

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

I did that, but still required manual fixing (?). Still the point is the same: checkstyle is necessary, but order of imports and while lines in between them is too much IMHO (I know it's the default, but that doesn't mean I have to agree with it anyway) :)

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

I did that, but still required manual fixing (?)

Well, I fix 99% formatting issues by "autoformat code" shortcut. Imports included. IDEA arranges those automatically just fine.

PS. The strict order of imports reduces the number of potential merge-conflicts.

This comment has been minimized.

@ahachete

ahachete Jun 13, 2017

Contributor

Yepp, that I did. Intellij + autoformat code. And checkstyle was still crying out loud. I guess it doesn't understand the difference between "external imports" and "special imports". I didn't understand it either, so I did trial and error after running autoformat. That autoformat caused all the changes to formatting that you were referring to before.

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

That autoformat caused all the changes to formatting that you were referring to before.

Well, you could confine autoformat to the selection.

Here's what I have:
import_order
import_order_rest

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

OK, I saw now what you meant. I left the original code as it was before the commit and made sure formatting only affects the new code. Now there's no other option but to squash my commits and submit them as a single commit with all changes so far. I will follow-up with that soon.

@@ -604,6 +625,24 @@ private void doAuthentication(PGStream pgStream, String host, String user, Prope
sspiClient.continueSSPI(l_msgLen - 8);
break;
case AUTH_REQ_SASL:
if (LOGGER.isLoggable(Level.FINEST)) {
LOGGER.log(Level.FINEST, " <=BE AuthenticationSASL");

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

There's no need to verify isLoggable when arguments to LOGGER.log are trivial. In this case, message is just passed as is, and no arrays created, so isLoggable should be just dropped.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Agreed.

private ScramSession.ClientFinalProcessor clientFinalProcessor;
private static void log(Level level, String message, Object... args) {
if (LOGGER.isLoggable(level)) {

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

LOGGER.isLoggable makes no sense here, and I'm not sure the method is justified. Well, it does shorten LOGGER.log( to just log(, however I would just call LOGGER field as log.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

It makes the code much more readable, because the if and then the very long lines end up requiring 4-5 lines to just log something. With the method, it is much more concise. And this is a method that should be inlined so why worry?

private static void throwConnectionRejectedException(String message, Object... args)
throws PSQLException {
throw new PSQLException(
GT.tr(message, args),

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

I think this defeats the whole purpose of "message localization". As far as I know, gettext looks for GT.tr tokens and creates boilerplate.properties files with a set of messages to be translated.
It look like this usecase would defeat gettext, and automatic discovery of strings would not work.

Please inline the method to the call sites.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Hmmm I don't know how that gettext automatic discovery works, but inline as suggested if that would break it. Still puzzled about this, code now is clunkier, but so be it...

@FunctionalInterface
private interface BodySender {
void sendBody(PGStream pgStream) throws IOException;

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

Isn't Consumer<PGStream> just enough?

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Unfortunately not, because of the IOException thrown

s.send(scramMechanismName.getBytes(StandardCharsets.UTF_8));
s.sendChar(0); // List terminated in '\0'
s.sendInteger4(clientFirstMessage.length());
s.send(clientFirstMessage.getBytes(StandardCharsets.UTF_8));

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

This seems to assume getBytes(StandardCharsets.UTF_8) == clientFirstMessage.length().
Is it always the case? If so, please clarify (i.e. in comments) why.

Otherwise I'm inclined to use byte[].length instead of String.length here (and below)

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Good catch. Almost all the message parameters are base-64 encoded, and separators are ASCII, but at least the username, after string prep, may be >1byte/char. Changed to byte[].length

authenticationMessageSender(
s -> s.send(clientFinalMessage.getBytes(StandardCharsets.UTF_8)),
clientFinalMessage.length()

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

byte vs char length issue possible.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Done

try {
clientFinalProcessor.receiveServerFinalMessage(serverFinalMessage);
} catch (ScramParseException e) {
throwConnectionRejectedException("Invalid server-final-message: {0}", serverFinalMessage);

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

Should the original exception be tied to the thrown one as a cause? The same for two other catch blocks below.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Agreed.

break;
case AUTH_REQ_SASL_CONTINUE:
scramAuthenticator.processServerFirstMessage(l_msgLen - 4 - 4);

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

What -4-4 means here?

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Check the message format. It is two ints. I hate this format, but the code is spread with this kind of calculations all the time. I wouldn't do it like this, but I don't want to refactor all this code here, so I just followed the pattern....

try {
serverFirstProcessor = scramSession.receiveServerFirstMessage(serverFirstMessage);
} catch (ScramException e) {
throwConnectionRejectedException("Invalid server-first-message: {0}", serverFirstMessage);

This comment has been minimized.

@vlsi

vlsi Jun 13, 2017

Member

Please propagate the source exception as a cause.
It would be extremely hard to debug the code in case there's ScramException for some reason.

This comment has been minimized.

@ahachete

ahachete Jun 14, 2017

Contributor

Done

@ahachete

This comment has been minimized.

Contributor

ahachete commented Jun 13, 2017

Thank you @sehrope and @vlsi for all your comments. Initially, I agree with most of them, and I will try to address them in a following commit soon :)

@ahachete

This comment has been minimized.

Contributor

ahachete commented Jun 13, 2017

BTW, comments here are invaluable.

However, don't forget this is using an external dependency, https://github.com/ongres/scram/, which took more than 95% of the work to support this functionality. Even if it is still a WIP, if comments or PRs could be done there, I would greatly appreciate it.

@sehrope

This comment has been minimized.

Contributor

sehrope commented Jun 13, 2017

Sure will do. Was already planning on a deeper dive into the SCRAM lib itself. Figured I'd start off with the pgjdbc piece to get a feel for the API prior to getting into the SCRAM details.

@ahachete

This comment has been minimized.

Contributor

ahachete commented Jun 14, 2017

Submitted a refactored new commit, with all the comments above (except java6/7 compilation, that's TODO, commits/diffs welcome) fixed or commented. Please review. Thanks.

@vlsi

This comment has been minimized.

Member

vlsi commented Jul 1, 2017

Regarding "include the feature in JRE8 build only", the current pattern for test code is to place relevant functionality into .jdbc41., .jdbc42. packages.

For instance pgjdbc-jre7 excludes execution of jdbc42 tests: https://github.com/pgjdbc/pgjdbc-jre7/blob/master/pom.xml#L29-L34

However, we don't have such excludes for the main code yet.
So the questions are:

  1. Is having JRE-vesion-specific package a proper way to go? I guess so.
  2. What name should JRE8-specific package have. Should it be org.postgresql.jdbc42 or org.postgresql.jre8? I'm inclined to org.postgresql.jre8. Well, we could have both at the same time, and use those wisely. For instance, put JDBC4.2-related functionality to .jdbc42. and JRE8-only featuers to .jre8.

If that is the case, scram client helper classes should land to something like org.postgresql.jre8.sasl.ScramAuthenticator and so on.

@davecramer , @sehrope what do you think?

@codecov-io

This comment has been minimized.

codecov-io commented Jul 6, 2017

Codecov Report

Merging #842 into master will decrease coverage by 0.36%.
The diff coverage is 1.16%.

@@             Coverage Diff              @@
##             master     #842      +/-   ##
============================================
- Coverage     65.96%   65.59%   -0.37%     
  Complexity     3589     3589              
============================================
  Files           167      168       +1     
  Lines         15333    15419      +86     
  Branches       2484     2487       +3     
============================================
  Hits          10114    10114              
- Misses         4042     4128      +86     
  Partials       1177     1177
@vlsi

This comment has been minimized.

Member

vlsi commented Jul 13, 2017

Update: the PR is not yet ready for merge. Need to figure out the way dependency should be managed (optional dependency or shaded into the pgjdbc)

@vlsi

This comment has been minimized.

Member

vlsi commented Sep 25, 2017

@ahachete , would you please add maven-shade... to get the library shaded?

@ahachete

This comment has been minimized.

Contributor

ahachete commented Oct 8, 2017

Rebased all 4 patches to current master

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 12, 2017

@ahachete @vlsi any suggestions on naming conventions for the jar now that it is shaded ? One option is to not change the name at all ?

<dependency>
<groupId>com.ongres.scram</groupId>
<artifactId>client</artifactId>
<version>1.0.0-beta.2</version>

This comment has been minimized.

@jorsol

jorsol Oct 12, 2017

Contributor

Will this be a beta dependency?

This comment has been minimized.

@vlsi

vlsi Oct 12, 2017

Member

That bothers me a bit as well.

This comment has been minimized.

@ahachete

ahachete Oct 12, 2017

Contributor

I was planning on bumping it to 1.0.0 when it is well tested and ready to be integrated. So if you feel this is OK, I will proceed and release 1.0.0 and update the PR.

This comment has been minimized.

@jorsol

jorsol Oct 12, 2017

Contributor

@ahachete well, it will never be tested if it's not included in pgjdbc, so is a chicken-egg problem, it's your code, so you better know if it is well tested.

I'm Ok if it's released as a Beta feature, mark it as such in release notes and if everything goes fine, bumping it to 1.0.0 and update it for the next release cycle.

@vlsi

This comment has been minimized.

Member

vlsi commented Oct 12, 2017

+1 for keeping the same jar name

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 12, 2017

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 12, 2017

@ahachete

This comment has been minimized.

Contributor

ahachete commented Oct 19, 2017

For the last three runs of Travis, due to this PR rebase or pushing new commits, like Dave Cramer's commit to shade the JAR, Travis is failing one test. But one different each time. And tests fail on non pgjdbc related stuff. You can see latest one, it falied when test when doing apt-get to install the oracle VM.

In other words: the above message is wrong, patches are working but Travis is randomly and even I'd say consistently failing. Apart from having to "ignore" it, any suggestions are welcome.... or am I missing something here?

Also @vlsi let me know if your requested changes are already implemented (should be) to close this request. Thanks.

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 19, 2017

@ahachete

This comment has been minimized.

Contributor

ahachete commented Oct 19, 2017

Good to know @davecramer But on previous runs I saw one other test failing (one of the 9.4 variants IIRC). And previously, another one. In other words: Travis seems lately a bit unreliable....

@vlsi

This comment has been minimized.

Member

vlsi commented Oct 19, 2017

In other words: Travis seems lately a bit unreliable

Does that imply you know a reliable CI system?

@ahachete

This comment has been minimized.

Contributor

ahachete commented Oct 19, 2017

No, I mostly use Travis everywhere. I just wanted to raise the fact, as the checks seem to be failing, but they "are not". Please review if you can lift your requested changes, other than this I believe PR is ready to be merged...

@ahachete

This comment has been minimized.

Contributor

ahachete commented Oct 19, 2017

If you can review it @davecramer ... thanks

@vlsi

This comment has been minimized.

Member

vlsi commented Oct 19, 2017

unzip -l postgresql-42.1.5-SNAPSHOT.jar

 1626  10-19-2017 17:21   org/postgresql/xa/PGXADataSource.class
     1669  10-19-2017 17:21   org/postgresql/xa/PGXADataSourceFactory.class
      853  10-19-2017 17:21   org/postgresql/xa/PGXAException.class
     2514  10-19-2017 17:21   org/postgresql/xa/RecoveredXid.class
        0  10-19-2017 17:21   com/
        0  10-19-2017 17:21   com/ongres/
        0  10-19-2017 17:21   com/ongres/scram/
        0  10-19-2017 17:21   com/ongres/scram/common/
        0  10-19-2017 17:21   com/ongres/scram/common/exception/
      586  10-19-2017 17:21   com/ongres/scram/common/exception/ScramException.class
     1565  10-19-2017 17:21   com/ongres/scram/common/exception/

The purpose of shading is to alter the package name (com.ongres -> org.postgresql.shaded.com.ongres) to avoid conflicts.

Would you please fix that?

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 19, 2017

ahachete added some commits Jun 11, 2017

Add SCRAM-SHA-256 support
PostgreSQL 10 comes with SCRAM-SHA-256 support. This commit introduces
support for it.

Work is based on an external dependency, the SCRAM client library:

	https://github.com/ongres/scram/

which is now imported as a dependency.

TODO:
	- SCRAM client library will be improved, on its own.
	  Particularily, StringPrep support needs to be added. Final
	  version of pgjdbc will depend on v1.0
	- Testing
	- Probably macros to avoid this Java8-only code propagating to
	  Java < 8 versions of the driver
Prepare Java8-only code to be excluded for jre<=8
Actually implemented via macros by JDBC < 4.2.
@davecramer

This comment has been minimized.

Member

davecramer commented Nov 20, 2017

@ahachete what about bumping your client up to 1.0.0? Do you still think it needs more testing ? If so how ?

@davecramer davecramer merged commit befea18 into pgjdbc:master Nov 21, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@davecramer

This comment has been minimized.

Member

davecramer commented Nov 21, 2017

@praiskup seems this is failing the fedora build phase due to maven not finding the shade plugin in offline mode?

@wibrt

This comment has been minimized.

wibrt commented Nov 29, 2017

  • do you know when the support for scram-sha-256 will be released into the stable production release?
  • i read on https://jdbc.postgresql.org/development/todo.html that daily snapshots are a future plan, so the the only way is to build it with the instructions in this repo?
@vlsi

This comment has been minimized.

Member

vlsi commented Nov 29, 2017

i read on https://jdbc.postgresql.org/development/todo.html that daily snapshots are a future plan, so the the only way is to build it with the instructions in this repo?

Development builds are published in Maven Central for successful builds.
Unfortunately, SCRAM change fails FEDORA build, so the snapshot does not get published.

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 29, 2017

The beta SCRAM package is in Rawhide, let me please fix the CI then.

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 29, 2017

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 29, 2017

CI should be fixed again, travis is still running https://travis-ci.org/pgjdbc/pgjdbc/jobs/308971928 .. Thanks to everyone for help!

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 29, 2017

@wibrt

This comment has been minimized.

wibrt commented Nov 29, 2017

tnx for the replies, some feedback:

i did some basic tests, but get a java error using
https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/42.1.5-SNAPSHOT/postgresql-42.1.5-20171128.162021-48.jar
(the same error with -47 driver)

background:
$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
(which isn't in automated testsuite?)

the issued command:
$ java -cp ".:../drivers/postgresql-42.1.5-20171128.085125-47.jar:${CLASSPATH}" JdbcDemo_10

(the jar file is in that location, no typo; works with older drivers, but then the auth 10 error is thrown)

the error when
"
Exception in thread "main" java.lang.NoClassDefFoundError: org/postgresql/shaded/com/ongres/scram/client/ScramClient$ChannelBinding
at org.postgresql.jre8.sasl.ScramAuthenticator.processServerMechanismsAndInit(ScramAuthenticator.java:74)
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:621)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:226)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.(PgConnection.java:195)
at org.postgresql.Driver.makeConnection(Driver.java:451)
at org.postgresql.Driver.connect(Driver.java:253)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270)
at JdbcDemo_10.(JdbcDemo_10.java:13)
at JdbcDemo_10.main(JdbcDemo_10.java:28)
Caused by: java.lang.ClassNotFoundException: org.postgresql.shaded.com.ongres.scram.client.ScramClient$ChannelBinding
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
"

i'll check again when travis is finished

@praiskup

This comment has been minimized.

Member

praiskup commented Nov 29, 2017

@wibrt

This comment has been minimized.

@wibrt

This comment has been minimized.

wibrt commented Nov 29, 2017

tnx for the work, the annoying thing is this context is that scram-sha-256 is a serverside setting applied at user creation or alter time.

@vlsi

This comment has been minimized.

Member

vlsi commented Nov 29, 2017

META-INF/MANIFEST.MF contains unshaded class names

resolution:=optional,com.ongres.scram.common

rhavermans added a commit to bolcom/pgjdbc that referenced this pull request Jul 13, 2018

Add SCRAM-SHA-256 support (pgjdbc#842)
* Add SCRAM-SHA-256 support

PostgreSQL 10 comes with SCRAM-SHA-256 support. This commit introduces
support for it.

Work is based on an external dependency, the SCRAM client library:

	https://github.com/ongres/scram/

which is now imported as a dependency.

TODO:
	- SCRAM client library will be improved, on its own.
	  Particularly, StringPrep support needs to be added. Final
	  version of pgjdbc will depend on v1.0
	- Testing
	- Probably macros to avoid this Java8-only code propagating to
	  Java < 8 versions of the driver

* Prepare Java8-only code to be excluded for jre<=8

Actually implemented via macros by JDBC < 4.2.

* On HEAD all testing connections will use SCRAM

* Better error message for drivers w/o SCRAM support

* added configuration for shaded jar
remove any extraneous classes picked up in the shade plugin

rhavermans added a commit to bolcom/pgjdbc that referenced this pull request Jul 13, 2018

Add SCRAM-SHA-256 support (pgjdbc#842)
* Add SCRAM-SHA-256 support

PostgreSQL 10 comes with SCRAM-SHA-256 support. This commit introduces
support for it.

Work is based on an external dependency, the SCRAM client library:

	https://github.com/ongres/scram/

which is now imported as a dependency.

TODO:
	- SCRAM client library will be improved, on its own.
	  Particularly, StringPrep support needs to be added. Final
	  version of pgjdbc will depend on v1.0
	- Testing
	- Probably macros to avoid this Java8-only code propagating to
	  Java < 8 versions of the driver

* Prepare Java8-only code to be excluded for jre<=8

Actually implemented via macros by JDBC < 4.2.

* On HEAD all testing connections will use SCRAM

* Better error message for drivers w/o SCRAM support

* added configuration for shaded jar
remove any extraneous classes picked up in the shade plugin
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment