If the community agrees to get rid of Cassandra 3 that'll save me effort on the refactor after I add Cassandra 4 :) Otherwise those vulnerabilities would only be in a "new" Cassandra 3 services NAR that would not be included in the convenience binary.
On Fri, Mar 15, 2024 at 1:28 PM Joe Witt <[email protected]> wrote: > Mike, Matt, > > Happy to hear you both have active efforts or are interested in doing so. > Can you help me understand more specifically what that means for the > current set of components? > > The CVE hits are concerning and long standing. Supporting Cassandra 3 > implies the current set of dependencies would remain too right? > > Is the current set of components we have ones we want to retain? We > certainly need Cassandra components - but are the ones we have now the > right ones? > > Thanks > Joe > > On Fri, Mar 15, 2024 at 10:25 AM Matt Burgess <[email protected]> > wrote: > > > I'm actively working this, I pushed my branch up in case anyone wants to > > take a look [1]. The idea is to abstract the Cassandra API "up a couple > > levels" and provide implementations for Cassandra 3, 4, and eventually 5. > > For JDBC-like interfaces this is a PITA because of the API (Statement, > > PreparedStatement, BoundStatement, ResultSet, etc.) but I'm hoping we can > > find a common pattern for abstracting the third-party library > > implementation and API from the NiFi component (Processor, > > ControllerService, etc.) API. I think we're doing something similar for > > Kafka? > > > > Regards, > > Matt > > > > [1] https://github.com/mattyb149/nifi/tree/cassy4 > > > > > > On Fri, Mar 15, 2024 at 8:43 AM Mike Thomsen <[email protected]> > > wrote: > > > > > That’s been on my todo list for a little while but things kept coming > up. > > > I think I could get started on that now. Based on my initial research > it > > > appears that scylla uses the exact same api as datastax so supporting > > both > > > in a cql bundle should theoretically be fairly easy. > > > > > > > > > Sent from my iPhone > > > > > > > On Mar 14, 2024, at 6:18 PM, Joe Witt <[email protected]> wrote: > > > > > > > > Team, > > > > > > > > Cassandra remains a really important system to be able to send data > to. > > > > However, it seems like we've not maintained these well. We have what > > > > appears to be at least a full generation behind on client versions > (we > > > are > > > > on 3x vs 4x which is the latest stable with 5x apparently coming > > > shortly). > > > > > > > > We have components to send data, query data, and use Cassandra as a > > cache > > > > store. We have older mechanisms for json/avro and publish mechanisms > > for > > > > records. > > > > > > > > The libraries we do have depend on outdated versions of Guava and > > result > > > in > > > > many CVE hits. > > > > > > > > I am inclined to think we should deprecate the 1.x components and > > remove > > > > them as-is from the 2.x line. Then re-introduce them with record > only > > > > interfaces and built against the latest stable > > > Cassandra/Datastax/ScyllaDB > > > > interfaces. > > > > > > > > I'd love to hear thoughts from those closer to this space both as a > > user > > > > and developer so we can make good next steps. > > > > > > > > Thanks > > > > > >
