PostgreSQL JDBC 42.3.2/42.2.25 Security update

A security advisory has been created for the PostgreSQL JDBC driver. The driver provides the facility to instantiate plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.

However, the driver did not verify if the class implements the expected interface before instantiating the class.

The fix is to ensure that the class implements the expected interface. This has been fixed in version 42.2.25 and 42.3.2 Additionally the following was are some of the changes in 42.3.2 the full change log can be found here

Changed

• perf: read in_hot_standby GUC on connection PR #2334
• fix: we will ask the server if it supports GSS Encryption if gssEncryption is prefer or require PR #2396 remove the need to have a ticket in the cache before asking the server if gss encryptions are supported
• fix: throw SQLException for #getBoolean BIT(>1) PR #2386 Throw SQLException instead of ClassCastException when calling CallableStatement#getBoolean(int) on BIT(>1).
• perf: read in_hot_standby GUC on connection PR #2334
• Add cert key type checking to chooseClientAlias PR #2417

Added

• feat: Add authenticationPluginClassName option to provide passwords at runtime Adds authenticationPluginClassName connection property that allows end users to specify a class that will provide the connection passwords at runtime. Users implementing that interface must ensure that each invocation of the method provides a new char[] array as the contents will be filled with zeroes by the driver after use.Call sites within the driver have been updated to use the char[] directly wherever possible. This includes direct usage in the GSS authentication code paths that internally were already converting the String password into a char[] for internal usage. This allows configuring a connection with a password that must be generated on the fly or periodically changes. PR #2369 original issue Issue #2102
• feat: add tcpNoDelay option PR #2341 fixes Issue #2324
• feat: pg_service.conf and .pgpass support (jdbc:postgresql://?service=my-service) PR #2260 fixes Issue #2278

Fixed

• Use local TimestampUtil in PgStatement and PgResultset for thread safety PR #2291 fixes Issue #921 synchronize modification of shared calendar
• fix: PgObject isNull() was reporting the opposite fixes Issue #2411 PR #2414
• fix: default file name is ".pg_service.conf" on Windows (not "pg_service.conf") PR #2398 fixes Issue #2278
• fix: do not close refcursor after reading if fetchsize has been set fixes Issue #2227 PR #2371
• fix: rework gss authentication to use the principal name to get the credentials fixes Issue #2235 PR #2352
• fix: return getIndexInfo metadata columns in UPPER CASE PR #2368
• fix: Connection leak in ConnectionFactoryImpl#tryConnect PR #2350 Issue #2351
• fix: Fix For IS_AUTOGENERATED Flag PR #2348
• fix: parsing service file tests for windows PR #2347
• fix: The spec says that calling close() on a closed connection is a noop. PR #2345 fixes Issue #2300
• fix: add microsecond precision to getTimestamp() called on sql TIME(6) Currently, "when fetching a value of type TIME(6) through resultSet.getTimestamp() only ms precision is retained, the microsecond fractional digits are lost." This change will retain the microsecond precision when .getTimestamp() is called on TIME(6). PR #2181 Closes Issue #1537
• test: materialized view privileges PR #2209 add and drop a materialized view Add to TestUtil and also to DatabaseMetaData setup and teardown fixes Issue #2060
• fix: typo in connect.md PR #2338 OutOfMemoryException => OutOfMemoryError
• fix: use local TimestampUtil in PgStatement and PgResultset for thread safety TimestampUtil is not thread safe. It raises exceptions when multiple threads use ResultSets of one connection. PR #2291 fixes Issue #921 If PgStatement and PgResultSet use their own TimestampUtil no synchronize is needed.
• fix: typo in CONTRIBUTING.md PR #2332 seccion => section

The PostgreSQL JDBC team would like to thank all that have participated in this release!

The JDBC Team