Need Help - Kafka instead of RabbitMQ

[V Palani]

Hello,

Myself Vijayakumar Palani and working in Volvo. Planning to implement a POC using Eiffel. 

We would like integrate pipelines of the our Software flow with an external supplier. In order to provide traceability, speed and handle the complexity of interconnected, interdependent and cross-organizational pipelines, an event-driven approach to manage the CICD pipelines is needed.

We found Eiffel and would like to use as sample implementation to find whether it meets with our expectation or not. Since, it is open-source event protocol for CICD pipelines. The current version yields several vulnerabilities in scanning.

Especially, amqp-client library, https://mvnrepository.com/artifact/com.rabbitmq/amqp-client/5.6.0

My questions are:

1. Can we use Kafka instead of RabbitMQ? Whether it is possible to implement Kafka in place of RabbitMQ for avoiding the vulnerabilities.
2. Is any alternate library available to use instead of avoiding RabbitMQ and avoiding amqp-client?

Please suggest to meet our expectation. 

Thanks and Regards,

Vijayakumar Palani

Sweden

[Emil Bäckmark]

Hi Vijayakumar,

 

Thanks for reaching out, and it’s great to hear about your intentions with a PoC on Eiffel including cross-organizational pipelines! I look forward to hearing some conclusions from that PoC in due time :)

 

About your issue on the amqp client. There are a lot newer amqp client versions out there, so I’d say the easiest way should probably be to uplift any event-aware service that you intend to use to a more recent version that doesn’t have those CVEs.

 

Regarding Kafka, it should be perfectly fine to use Eiffel over Kafka instead of RabbitMQ. I have no experience in trying Eiffel over Kafka though, and I don’t know of anyone else in the community who has done that yet either. I would assume that you would come to valuable conclusions quicker in your PoC if you choose to use an upgrade amqp library instead of Kafka, but it would be great to hear about any conclusions you might come to if you decide to try out Kafka for Eiffel.

 

Out of curiosity, do you intend to use any of the existing services/tools in the Eiffel landscape for your PoC, and if so which ones, or do you intend to implement it all from scratch?

 

BR,

Emil, Eiffel Technical Committee

--
You received this message because you are subscribed to the Google Groups "Eiffel Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-community/f2919710-2d48-4494-9c95-60a76278ae6bn%40googlegroups.com.

[V Palani]

Hello,

Thanks you for your reply. Our plan to use Eiffel Broadcaster Plugin from Jenkins. Is it possible to use Kafka with this Plugin?  

We would like to know more about vulnerability part as well. Jenkins plugin dev team also can help here to get to know more about on this. 

Regards,

Vijayakumar Palani

[Magnus Bäck]

I'm happy to see your interest in the eiffel-broadcaster plugin! I'm the primary maintainer of it. Like all open source components in the Eiffel ecosystem it only supports RabbitMQ. I'm not able to find information about any vulnerabilities in amqp-client 5.6.0 (I googled and searched the NVD and MITRE databases), but either way the library is really outdated and should be upgraded. You're saying that you don't have any additional information any vulnerabilities?

Cheers,

Magnus

[V Palani]

Hello,

Thank you for your great response. While analyzing, we came across to this

https://mvnrepository.com/artifact/com.rabbitmq/amqp-client/5.6.0

From there, we have identified the vulnerabilities existing while using the RabbitMQ. Could you verify and clarify to us whether the vulnerabilities issues has been resolved in latest version or not? 

Thanks

Vijayakumar Palani

[Magnus Bäck]

Ah, you're referring to the vulnerabilities in the dependencies of amqp-client. All the listed CVEs are in the Jackson library (most, if not all, in jackson-databind), except one that's in JUnit (obviously not a problem in production use). Now, the version of the Jackson library that's actually used in a Jenkins instance will be determined by the Jackson 2 API plugin, not by what each plugin's POM says. In fact, if you peek inside the plugin .hpi file, the Jackson jar isn't even there since it's expected to be supplied by Jenkins.

$ unzip -l ~/src/eiffel-broadcaster-plugin/target/eiffel-broadcaster.hpi | grep jar                              
    13674  2021-02-22 22:21   WEB-INF/lib/packageurl-java-1.2.0.jar
   191591  2021-07-06 20:58   WEB-INF/lib/json-schema-validator-1.0.43.jar
   600738  2022-12-02 15:22   WEB-INF/lib/amqp-client-5.6.0.jar
   246918  2021-01-01 21:31   WEB-INF/lib/commons-beanutils-1.9.4.jar
   588337  2021-01-01 21:31   WEB-INF/lib/commons-collections-3.2.2.jar
   196768  2021-01-01 21:31   WEB-INF/lib/commons-digester-2.1.jar
   189675  2021-01-01 21:31   WEB-INF/lib/commons-validator-1.7.jar
   577742  2021-01-01 22:43   WEB-INF/lib/commons-lang3-3.11.jar
  1685713  2021-07-06 20:58   WEB-INF/lib/jcodings-1.0.46.jar
   214804  2021-07-06 20:58   WEB-INF/lib/joni-2.1.31.jar
    61409  2022-12-02 23:16   WEB-INF/lib/slf4j-api-2.0.3.jar
   332343  2023-08-09 14:47   WEB-INF/lib/eiffel-broadcaster.jar

Cheers,

Magnus

[Magnus Bäck]

I just released v2.6.2 of the eiffel-broadcaster plugin, and it includes an upgrade of the amqp-client library that presumably references a fresh Jackson dependency (even though it doesn't matter). The new library version also addresses a DoS vulnerability, but it doesn't apply to the plugin either since the bug only affects consumers of messages.

Cheers,

Magnus