backport the fix of CVE-2022-31197 to 42.3.x releases to support spring-boot dependencies

[dbahatSAP]

Hi,

in GHSA-r38f-c4h4-hqq2 it was stated that

We are not releasing a version for the 43.3.x release line and users are advised to upgrade to the 42.4.1 release to get the fix.

Spring-boot projects 2.6.x and 2.7.x are dependent in 43.3.x release line and upgrading them seem to involve efforts (see spring-projects/spring-boot#32126).
Would it be possible to keep maintaining security fixes for the 43.3.x release line, at least until spring boot 3 (which is based on the 43.4.x release line) gets officially released?

Thanks,
-David

[vlsi]

The key driver for 42.3 -> 42.4 is #2425 which is basically restoring to pre-42.2.5 behavior by default.

Do you really think you can't upgrade to 42.4?

[snicoll]

FTR there's no effort involved. Our upgrade policy is so that we won't upgrade to a new feature version of a third-party dependency in a maintenance release of Spring Boot (see our wiki). Users can override the postgresql.version but it would be nice if the CVE fix was backported if possible.

[davecramer]

So the challenge I have here is that we really don't want to support multiple branches. While we could backpatch 42.3.x it would set a precedent that we don't want. We are pretty liberal with bumping the version with any new changes. By setting this precedent it would make this liberal policy harder to uphold. Unless absolutely necessary, I'd prefer not to backpatch. Dave Cramer

…

On Mon, 22 Aug 2022 at 10:15, Stéphane Nicoll ***@***.***> wrote: FTR there's no effort involved. Our upgrade policy is so that we won't upgrade to a new feature version of a third-party dependency in a maintenance release of Spring Boot (see our wiki <https://github.com/spring-projects/spring-boot/wiki/Supported-Versions#third-party-dependencies>). Users can override the postgresql.version but it would be nice if the CVE fix was backported if possible. — Reply to this email directly, view it on GitHub <#2599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADDH5UBNHKL3QTQDJO526TV2ODPVANCNFSM57G2CLEA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dbahatSAP]

@davecramer we are only talking about security hotfixes / CVEs. And despite the liberal policy I'm only seeing 3 major version bumps in the last 5 years.
@snicoll I might be missing something, but doesn't Spring Boot support wiki states 3.0.x generation (which uses pgjdbc 42.4.x) is only due around November 2022? Are we really expecting all the Spring-Boot ecosystem to manually override this in the meantime?

Any chance for a compromise here?

[snicoll]

We've already discussed this as a team and declined the upgrade, see spring-projects/spring-boot#32126

[davecramer]

@dbahatSAP Agreed we only have 3 major version bumps in the last 5 years. However I'm just about to release another one.

I guess the compromise would be to only back patch security fixes.
I'll discuss internally

[jorsol]

Our upgrade policy is so that we won't upgrade to a new feature version of a third-party dependency in a maintenance release of Spring Boot (see our wiki).

This policy is strange, not all projects follow strict semver, and if a project doesn't keep multiple branches (as is normally the case with pgjdbc) then all the spring projects could end up using dependencies with vulnerabilities, and as Spring Boot 2.7.x is going to have a longer than usual support time (as probably jumping from 2.x to 3.x is going to take a while), then there are greater chances of getting stuck with vulnerable dependencies.

I wonder how it's handled the case for 2.5.x and 2.4.x with Commercial support, as those versions are using pgjdbc 42.2.x, it's expected that the user just overrides the postgresql.version? (and the same with every other dependency?)

Anyway, if "users can upgrade safely themselves if they so wish", then there are no strong reasons to backport to 42.3.x either.

[philwebb]

This policy is strange, not all projects follow strict semver, and if a project doesn't keep multiple branches (as is normally the case with pgjdbc) then all the spring projects could end up using dependencies with vulnerabilities, and as Spring Boot 2.7.x is going to have a longer than usual support time (as probably jumping from 2.x to 3.x is going to take a while), then there are greater chances of getting stuck with vulnerable dependencies.

It is indeed a bit of a balancing act. Some projects like pgjdbc might have good back compatibility guarantees and it would be relatively safe to upgrade in a patch release, however, many other projects aren't so disciplined. The policy is really designed to keep our users in control of things. Most prefer to not have unexpected version bumps when they change the patch version of Spring Boot. Security tools are also pretty good at flagging vulnerable dependencies and then users can make an informed choice about upgrading or accepting the risk.

Anyway, if "users can upgrade safely themselves if they so wish", then there are no strong reasons to backport to 42.3.x either.

Fair enough. If we ever release a 2.8 (not currently planned) we'll bump to the latest version.

[davecramer]

Fair enough. If we ever release a 2.8 (not currently planned) we'll bump to the latest version.

This is the best case scenario for us. I do realize Spring has quite a few commercial users and their version requirements would be quite varied.

I'm really trying to keep the ability to move forward easily while also being able to react quickly to security vulnerabilities.

Regards,

Dave

[davecramer]

Decided not to fix.

[davecramer]

I have released 42.3.7 so you should be able use this in spring now

[snicoll]

@davecramer thank you very much. I've upgraded Spring Boot 2.6.x and 2.7.x to that version, which will be released later this month.

[sparty02]

I have released 42.3.7 so you should be able use this in spring now

@davecramer thanks for making the 42.3.x patch. However, the CVE/advisory still reflect 42.3.7 as an affected version (which impacts downstream scanning tools that use this metadata to alert on vulnerabilities). Is there a way to get that updated?

[vlsi]

Indeed. I've updated GHSA-r38f-c4h4-hqq2

[sparty02]

thanks @vlsi! can you also update this statement in the Patches section?

We are not releasing a version for the 43.3.x release line and users are advised to upgrade to the 42.4.1 release to get the fix.

[sparty02]

Also, does this information automatically flow down to the other CVE databases? (i.e. NVD)

[vlsi]

Also, does this information automatically flow down to the other CVE databases? (i.e. NVD)

Frankly speaking, I've no idea, however, we published the CVE through GitHub only, and it somehow appeared in NVD.