-
Notifications
You must be signed in to change notification settings - Fork 15
Bump PostgreSQL driver from 42.3.3 -> 42.4.1 to remediate CVE-2022-31197 #6205
Conversation
Generate changelog in
|
@@ -88,7 +88,7 @@ uk.org.lidalia:slf4j-test = 1.1.0 | |||
com.datastax.cassandra:cassandra-driver-core = 3.8.0 | |||
com.oracle.database.jdbc:ojdbc11 = 21.5.0.0 | |||
com.palantir.cassandra:* = 2.2.13-1.6.0 | |||
org.postgresql:postgresql = 42.3.3 | |||
org.postgresql:postgresql = 42.4.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we bump to 42.4.2 or 42.5.0? see #6206
From https://jdbc.postgresql.org/documentation/changelog.html#version_42.5.0
Version 42.5.0 (2022-08-24)
Notable changes
Changed
- fix: revert change in PR #1986 where float was aliased to float4 from float8. float now aliases to float8 PR #2598 fixes Issue #2597
Version 42.4.2 (2022-08-17)
Notable changes
Changed
- fix: add alias to the generated getUDT() query for clarity (PR [TimeLock] Conflicting Path Param Names in Lock Service #2553)[https://github.com/Add table alias to the getUDT query for clarity pgjdbc/pgjdbc#2553]
Added
- fix: make setObject accept UUID array PR #2587
Fixed
- fix: regression with GSS. Changes introduced to support building with Java 17 caused failures Issue #2588
- fix: set a timeout to get the return from requesting SSL upgrade. PR #2572
- feat: synchronize statement executions (e.g. avoid deadlock when Connection.isValid is executed from concurrent threads)
Version 42.4.1 (2022-08-03)
Notable changes
Security
- fix: CVE-2022-31197 Fixes SQL generated in PgResultSet.refresh() to escape column identifiers so as to prevent SQL injection.
Previously, the column names for both key and data columns in the table were copied as-is into the generated SQL. This allowed a malicious table with column names that include statement terminator to be parsed and executed as multiple separate commands.
Also adds a new test class ResultSetRefreshTest to verify this change.
Reported by Sho KatoChanged
- chore: skip publishing pgjdbc-osgi-test to Central
- chore: bump Gradle to 7.5
- test: update JUnit to 5.8.2
Added
- chore: added Gradle Wrapper Validation for verifying gradle-wrapper.jar
- chore: added "permissions: contents: read" for GitHub Actions to avoid unintentional modifications by the CI
- chore: support building pgjdbc with Java 17
Version 42.4.0 (2022-06-09)
Notable changes
Changed
- fix: added GROUP_STARTUP_PARAMETERS boolean property to determine whether or not to group startup parameters in a transaction (default=false like 42.2.x) fixes Issue Include 0.59.1 in release notes #2425 pgbouncer cannot deal with transactions in statement pooling mode PR Include 0.59.1 in release notes #2425
Fixed
- fix: queries with up to 65535 (inclusive) parameters are supported now (previous limit was 32767) PR Nziebart/cassandra sweep batch size #2525, Issue make tests reuse resources #1311
- fix: workaround JarIndex parsing issue by using groupId/artifactId-version directory namings. Regression since 42.2.13. PR Feature/sweep outcome metrics #2531, issue SLS-style request logs do not capture timelock client #2527
- fix: use Locale.ROOT for toUpperCase() toLowerCase() calls
- doc: add Vladimir Sitnikov's PGP key
- fix: return correct base type for domain from getUDTs PR TimeLock + Async Initialization, Part 1 #2520 Issue compare cassandra revert to 0.60.0 #2522
- perf: utcTz static and renamed to UTC_TIMEZONE PR Add note that Schema V2 is a beta feature #2519
- doc: fix release version for sweep faster #2377 (it should be 42.3.6, not 42.3.5)
Version 42.3.6 (2022-05-24)
Notable changes
Fixed
- fix: close refcursors when underlying cursor==null instead of relying on defaultRowFetchSize PR sweep faster #2377
Version 42.3.5 (2022-05-04)
Notable changes
Known issues
- Regression since 42.3.2: "cursor does not exist" when using ResultSet.setFetchSize from CallableStatement, fixed in 42.3.6 (see PG sweep faster #2377)
Changed
- test: polish TimestampUtilsTest
- chore: use GitHub Action concurrency feature to terminate CI jobs on fast PR pushes
Added
- Added KEYS file to allow for verifying artifacts PR 2499
Fixed
- perf: enable tcpNoDelay by default PR 2495. This is a regression from 42.2.x versions where tcpNoDelay defaulted to true
- docs: fix readme.md after PR 2495 PR 2496
- feat: targetServerType=preferPrimary connection parameter PR 2483
- fix: revert removal of toOffsetDateTime(String timestamp) fixes Issue DbKvs sweep refactors to address last PR comments #2497 PR 2501
Version 42.3.4 (2022-04-15)
Notable changes
Known issues
- Regression since 42.3.2: "cursor does not exist" when using ResultSet.setFetchSize from CallableStatement, fixed in 42.3.6 (see PG sweep faster #2377)
Changed
- fix: change name of build cache PR 2471
- feat: add support for ResultSet#getObject(OffsetTime.class) and PreparedStatement#setObject(OffsetTime.class) PR 2467
- fix: Use non-synchronized getTimeZone in TimestampUtils PR 2451
- docs: Fix CHANGELOG.md misformatted markdown headings PR 2461
- docs: remove loggerLevel and loggerFile from docs and issues Autodelegate generates too many build warnings #2489
- feat: use direct wire format -> LocalDate conversion without resorting to java.util.Date, java.util.Calendar, and default timezones PR 2464 fixes Issue Use getBytes over getBlob, as our Oracle driver doesn't support getBlob #2221
Fixed
- docs: Update testing documentation PR 2446
- fix: Throw an exception if the driver cannot parse the URL instead of returning NULL fixes Issue More hints for getRange() on Oracle #2421 PR 2441
- fix: Use PGProperty instead of the property names directly PR 2444
- docs: update changelog, missing links at bottom and formatting PR 2460
- fix: Remove isDeprecated from PGProperty. It was originally intended to help produce automated docs. Fixes #Issue 2479 PR 2480
- fix: change PGInterval parseISO8601Format to support fractional second PR 2457
- fix: More test and fix for issues discovered by PR Feature/serialisable tm initialise check #2476 PR 0.60 release notes #2488
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For safety, I went with the version that has the fix and that our large internal postgres user uses. We can definitely evaluate going higher (and evaluating the risks), but I think we should stick to the lower version that's been tested. cc @jeremyk-91 in case you have other thoughts!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's get this out first, we can do the .5.0 one in a bit once things are stabler? We've had historic badness with this driver in the past unfortunately
👍 |
Released 0.695.0 |
General
Before this PR:
PostgreSQL driver 42.3.3 has a CVE. 42.2.26 and 42.4.1 have fixes for CVE-2022-31197.
Large internal product has picked up 42.4.1.
After this PR:
==COMMIT_MSG==
Bump PostgreSQL driver from 42.3.3 -> 42.4.1 to remediate CVE-2022-31197
==COMMIT_MSG==
Priority: P0
Concerns / possible downsides (what feedback would you like?):
Is this safe?! Internal product uses this version, and has done for a week. The difference in versions is 6 months, so changelog hunting yields limited results.
Is documentation needed?:
Changelog at least.
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?:
N/A
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?:
Not according to changelogs.
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.):
Nothing that indicates otherwise from changelogs.
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?:
Nothing that indicates otherwise from changelogs.
Does this PR need a schema migration?
No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?:
None
What was existing testing like? What have you done to improve it?:
No changes
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.:
N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?:
N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.):
No change in any metrics or logs.
Has the safety of all log arguments been decided correctly?:
N/A
Will this change significantly affect our spending on metrics or logs?:
N/A
How would I tell that this PR does not work in production? (monitors, etc.):
AtlasDB fails to connect to Postgres. AtlasDB fails transactions with Postgres that previously succeeded/
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?:
Rollback.
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
That's me!
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.:
N/A
Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?:
N/A
Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?:
N/A
Development Process
Where should we start reviewing?:
It's +2 -2
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?:
...
Please tag any other people who should be aware of this PR:
@jeremyk-91
@sverma30
@raiju