Fix CVE-2022-24329
catap opened this issue · 11 comments
To fix CVE-2022-24329 Kotlin should be updated to 1.6.0.
The last stable release 4.9.3 uses 1.4.10 which is vulnerable to this CVE.
Is it possible to used Kotlin version on stable branch and release 4.9.4?
Thanks!
That CVE is for the compiler and only for Kotlin/JS targets. Since the released artifacts are already built they are not susceptible. Since we are not using Kotlin/JS we are also not susceptible.
@JakeWharton yes, but this CVE triggers a lot of scanners at some unexpected places.
for example the last release of akka discovere for consul depends on this project.
I'll reopen to discuss
@yschimke thanks. From my point of view such update should be quite minor and costs simple release old (stable?) version which make a lot of security scanners happy, allow to avoid ugly exclusion in in dependencies and possible ABI incompatibility in runtime.
I'm extremely uncomfortable making a patch release that changes a transitive dependency to a new minor version. It's a big violation of semver. A better fix would be 4.10.0, or 5.0.0.
We're not done 5.0.0, so it'd have to be 4.10.0.
4.10.0 might be a good point to make the transition to 5.0 slightly less of a jump. Take the Kotlin 1.6.20 hit now.
Regardless my experience has been it's easier to ship patches than to explain why they're unnecessary. So sure, let's do a round of patch releases.
It's pretty ridiculous that every project in the world needs to update their Kotlin version despite the fact that this only applies to build tools not shipped artifacts because of some broken CVE scanning tool.
I vote do nothing in protest.
@JakeWharton the root cause this issue that Kotlin made a fix for CVE only for one, the next, release without of any attempt to backport it to older version which is widely used.
Unfortunately this is a usual behaviour and a few days ago Scala.JS released a new version to fix CVE-2022-28355 which brokes a lot of things :(
Does the vulnerability(CVE-2022-24329) affect okhttp(4.9.3)?
According to the vulnerability description, I understand that the problem lies in the build phase. The constructed okhttp should not be affected.