2.57 pulls a protobuf problem via kotlin-metadata-jvm

[lepistone]

Hi! Since 2.57 added a dependency on kotlin-metadata-jvm, it is affected by a still open problem they have [1]: they are shipping code generated with a very old version of protoc, which is possibly affected by a CVE and can crash at runtime when running with protobuf-java >= 3.25.6.

Thanks!

[1] https://youtrack.jetbrains.com/issue/KT-74258/IR-Bump-Protobuf-compiler-version

[bcorso]

FWIW, previous to Dagger 2.57 we were shading the kotlin-metadata-jvm classes into the Dagger artifact. Thus, this likely isn't a new issue, it's just more obvious now.

That said, I also don't think there's anything we can do on our side until it's fixed upstream (Kotlin 2.3.0-Beta1), so I'll just leave this open until then.

[blakeli0]

What was the reason that Dagger 2.57 stopped shading kotlin-metadata-jvm? It should be fine for this specific issue because kotlin-metadata-jvm is also shading protobuf-java runtime. But in case kotlin-metadata-jvm stops shading protobuf-java in the future, Dagger would introduce diamond dependency problems to its customers that it requires a very old protobuf-java runtime version, which is not compatible with newer protobuf gen code.

If there are no compelling reasons, it would be great if Dagger can continue to shade kotlin-metadata-jvm in the future to keep the dependency tree as few as possible.

[bcorso]

What was the reason that Dagger 2.57 stopped shading kotlin-metadata-jvm?

By shading it ties a particular version of Dagger to a particular version kotlin-metadata-jvm, and also means we have to release Dagger anytime the dependency gets out of date (e.g. #4582). In addition, we only shaded initially because the library was unstable (i.e. pre 1.x) but now that it's APIs are more stable it should be better to unshade it. Unshading allows users to pull in the version of kotlin-metadata-jvm they need without requiring a Dagger release/update.

But in case kotlin-metadata-jvm stops shading protobuf-java in the future, Dagger would introduce diamond dependency problems to its customers that it requires a very old protobuf-java runtime version, which is not compatible with newer protobuf gen code.

Can you explain how it's a diamond dependency issue? Dagger doesn't depend on protobuf-java, so you should get whatever version of protobuf-java is coming from kotlin-metadata-jvm. Once the kotlin-metadata-jvm updates their shaded dependency it should fix things, right?

[blakeli0]

This is the current dependency tree, which is fine because protobuf-java is shaded.

customer's app -> dagger -> kotlin-metadata-jvm -> shaded protobuf-java 2.x gen code and runtime

In case kotlin-metadata-jvm decides not to shade protobuf-java 2.x anynore, Dagger would bring in protobuf-java transitively. If the customer also depends on another library that requires a different major version of protobuf-java 4.x, the customer would be stuck because protobuf-java 4.x and 2.x are not compatible with each other. See the new dependency tree as follows

customer's app -> dagger -> kotlin-metadata-jvm -> protobuf-java 2.x gen code and runtime
               -> library A -> protobuf-java 4.x gen code and runtime

Technically this is not a Dagger-only problem, it is the same problem for any library that depends on protobuf-java. But we could mitigate this problem by shading so that at least Dagger does not potentially contribute to this problem.

[bcorso]

Ah, yeah, like you said I don't see this as a Dagger problem.

While it would technically work if Dagger shaded both kotlin-metadata-jvm and protobuf-java, it also means every processor that depends on kotlin-metadata-jvm would need to do the same thing and you'd end up with something that's error-prone and bloated (each processor would come with its own copy).

Thus, I think the better solution if kotlin-metadata-jvm were to unshade protobuf-java would be file a bug to the kotlin-metadata-jvm team to either update their dependency on protobuf-java to something more recent or to re-shade it.