Add `camunda-only-bom` which doesn't include any third-party libraries

[cachescrubber]

Environment

7.20.0-alpha6

Description

Consider removing 3rd party dependencies from camunda-bom.

While reading camunda-bom pom.xml I noticed it includes dependency management for mybatis, joda-time and java-uuid-generator. IIRC a BOM should only provide dependency management for the modules managed directly by the project.

Solution Ideas

Move dependency management for 3rd party dependencies from the bom to the projects parent pom.

Hints

https://github.com/Azure/azure-sdk-for-java/issues/26136

[tasso94]

Hi @cachescrubber,

Thanks for raising this issue.

I'll get back with my insights as soon as possible.

Stay tuned!

Best, Tassilo

[tasso94]

Hi @cachescrubber,

Since Camunda 7 is not just a library but a platform, we want to ensure our users utilize third-party library versions our platform is tested with and don't mistakenly use versions that cause problems.

What is your use case in which you require the BOM not to contain third-party libraries? Does this cause any problems for you?

Best, Tassilo

[cachescrubber]

Hi @tasso94, thanks for coming back to my issue. I maintain a corporate maven parent where I include several BOMs from different sources. When third-party libraries are managed in one of those boms it becomes quite hard to analyse where the version is actually coming from. Why should I expect/How should I know e.g. joda-time is being version managed by the camundas bom? The notably exception in my case is the spring-boot-dependencies bom, where I rely on the spring team to manage a curated list of 3rd party versions.

Slightly off-topic, but related. The third party versions managed in the camunda-bom are quite outdated. Why is that?

version.mybatis: 3.5.6 => 3.5.13
version.joda-time: 2.1 => 2.12.5
version.uuid-generator: 3.2.0 => 4.3.0

Thanks, Lars

[tasso94]

Hi Lars,

I appreciate your feedback and the detailed explanation of your use case. We must understand your concerns to make our platform as user-friendly as possible. While we aim to provide a curated list of third-party libraries in our BOM, we also recognize the importance of transparency and flexibility, especially for users who maintain corporate Maven parents like yourself.

Given your feedback, we are open to discussing potential improvements in our approach. However, please keep in mind that our primary goal is to ensure the reliability and compatibility of our platform.

Here are two options we can explore:

1. Documentation: We can enhance our documentation to clarify which third-party libraries are being managed in our BOM. This way, you'll clearly understand which libraries are included and their versions.

2. Customization: We could consider providing another BOM containing only Camunda 7 libraries if they prefer to manage the third-party dependencies themselves. This would give you more control over the dependencies you want to manage independently.

Your input is valuable to us, and we're happy to find a solution that works for both your use case and our platform's goals. Please let us know which of these options, if any, you find most suitable or if you have any other suggestions that might help address your concerns. We want to ensure that our platform meets the needs of a diverse user base, and your insights are instrumental in achieving that.

Best, Tassilo

[cachescrubber]

Hi Tassilo,

I think both options combined would be ideal.

• camunda-bom containing only Camunda 7 libraries.
• create an additional camunda-dependencies including 3rd party libraries + camunda-bom.
• Document the managed third-party versions would be helpful.

Lars

[tasso94]

Hi @cachescrubber,

I'm afraid we cannot remove the third-party libraries from the camunda-bom for backward compatibility reasons.

However, we could introduce a camunda-only-bom containing only C7 libraries.

Would that help?

Best, Tassilo

[cachescrubber]

Hi @tasso94, Yes, that would help. I could easily change to camunda-only-bom.

[tasso94]

Hi @cachescrubber,

Cool! Would you be up for contributing the new BOM to our project via pull request?

The current BOM is located here: https://github.com/camunda/camunda-bpm-platform/blob/master/bom/pom.xml.

It might make sense to add two new modules in the bom directory:

./bom
|_ ./camunda-only-bom
|_ ./camunda-bom

Best, Tassilo

[cachescrubber]

Hi @tasso94 , please review #3863

[sidribeiros]

Hi all. Continuing on the off-topic outdated libraries.... There is a critical vulnerability (CVE-2019-17571) log4j that is used by java-uuid-generator. It was fixed in version 4. Is there a plan to upgrade it?

[tasso94]

Hi @sidribeiros,

Thank you for letting us know. Can you create a camunda security report? It is described here: https://camunda.com/trust-center/reporting-vulnerabilities/

Nevertheless, I'll have a look. Thank you!

Best, Tassilo

[tasso94]

Hi @cachescrubber,

Thank you for your contribution. I'll have a look.

Best, Tassilo

[cachescrubber]

Hi @tasso94,

In the meantime I raised a similar request with the Joinfaces project - see https://github.com/joinfaces/joinfaces/issues/1974. Finally they decided against backward compatibility and used a similar naming convention then I proposed in https://github.com/camunda/camunda-bpm-platform/issues/3795#issuecomment-1759498315. Anyway, I'm still fine with camunda-only-bom, just a FYI.

[tasso94]

Hi @cachescrubber,

It makes sense that joinfaces did it consistently like the spring boot project since joinfaces is a spring boot extension (starter).

In our case, however, spring boot is just one way of using Camunda 7. We have used this BOM structure for ten years, and I would opt for minimal migration effort for our users migrating from Camunda 7.20 to 7.21.

Best, Tassilo

[tasso94]

Hi @sidribeiros,

After carefully reviewing the situation, I can confirm that our product is not affected by the security vulnerability CVE-2019-17571.

The issue concerns the log4j dependency used by com.fasterxml.uuid:java-uuid-generator. The log4j library has a provided Maven scope. This means that it compiles against the classes of the affected library. Also, using log4j is optional when using com.fasterxml.uuid:java-uuid-generator as described here ^1. We don't bundle or ship a vulnerable version of this library.

To avoid this problem popping up in the future again in vulnerability scanners, I created with #3913 a task to bump com.fasterxml.uuid:java-uuid-generator for Camunda 7.21.0.

Does this answer your questions?

Best, Tassilo

[sidribeiros]

@tasso94 Yes. Thank you!

[tasso94]

Hi @cachescrubber,

Thank you for your contribution. I merged it with the master branch.

Best, Tassilo

[cachescrubber]

Thank you @tasso94 for listening and taking care of the PR.

I would like top come back to the remaining outdated 3rd party dependencies. Should I open issues / and or PRs similar to #3913, or do you take care of that yourself? Let me know.

[tasso94]

Hi @cachescrubber,

Bumping any third-party library is not an automatism in this project. We usually only bump them if there is a good reason. Do you want to see these libraries to be bumped to use features only available in higher versions of these libraries, or is there another reason? If it's the former, please create a feature request. We will then talk about the priority with product management.

Best, Tassilo

[cachescrubber]

Hi @tasso94

Bumping any third-party library is not an automatism in this project

I think during the last couple of years a general consensus in the industry has been established, that 3rd party dependencies should be kept up to date and are updated on a regular basis. Most important concern is of course supply chain security, but there are certainly more aspects. IMO projects (products) like yours have a special responsibility here, as you have many downstream users which rely on you to do so. Your 6 month release cycle should give plenty of opportunity to do so without risking stability of the product.

Best, Lars

[tasso94]

Hi Lars,

We know that this is quite different from how it is handled by other platforms elsewhere.

Also, we have this topic on our radar to explore further. In the past, one requirement was an efficient license check and a more stable CI. Both topics have been improved over the last year. We need to try it out and understand the topic better before changing our processes. Please bear with us that this cannot happen overnight.

Stay tuned!

Best, Tassilo

[cachescrubber]

Hi @tasso94,

I have created issues for mybatis and joda-time. Thank you for taking a more regular upgrade policy into consideration.

Best, Lars