Hi guys. This thread has been hanging for quite some time (no pun intended). While it was hanging, CVE-2022-22965 [1] was discovered which makes it extremely dangerous to have vulnerable versions of Spring as dependencies.
As discussed, ignite-extensions has 3 versions of spring-data integrations (against versions 1.0, 2.0, 2.2 of spring-data), namely ignite-spring-data, ignite-spring-data_2.0, ignite-spring-data_2.2. They use Spring versions 4.3.x, 5.0.x, 5.2.x, respectively. Of them, only 5.2 branch is still supported and got a fix for CVE-2022-22965. My suggestion is to implement what was suggested earlier in this thread: 1. Remove ignite-spring-data and ignite-spring-data_2.0 2. Update ignite-spring-data_2.2 module to depend on the latest Spring version in branch 5.2 (it's currently 5.2.21) 3. Probably also rename ignite-spring-data_2.2 extension to ignite-spring-data (dropping the version postfix). I created a Jira ticket [2]. Later, in a separate ticket (with no rush due to the urgency of the matter), we could update the integration to work with the most recent spring-data version. What are your thoughts? [1] - https://nvd.nist.gov/vuln/detail/CVE-2022-22965 [2] - https://issues.apache.org/jira/browse/IGNITE-16869 пт, 18 февр. 2022 г. в 20:58, Maksim Timonin <timoninma...@apache.org>: > > > My proposal is not about creating a separate repository for the spring-data > extension - just left a single module > > Yeah, you're correct. I mean that we need a single point of truth for > spring-data - single repository or single module. I'm +1 here. > > > So creating some branches to store obsolete code for a module seems a bit > confusing > > IMHO, we should have an opportunity to release a hot fix asap for those > modules in case of critical CVE, particularly if it is impossible to just > make an upgrade from 2.0 to 2.2 or to the latest version due to backward > compatibility. > > WDYT? > > On Fri, Feb 18, 2022 at 2:12 PM Mikhail Petrov <pmgheap....@gmail.com> > wrote: > > > Maksim, > > > > Currently, we have a single repository where all extensions are stored > > as separate modules - [1] > > My proposal is not about creating a separate repository for the > > spring-data extension - just left a single module for the spring-data > > extension and proceed with its developments the same way as for other > > extensions - [2]. > > So creating some branches to store obsolete code for a module seems a > > bit confusing. > > > > > > One of the goals of this refactoring is to create the Spring Data > > integration extension that will be independent of the version of Spring > > Data. > > (as it is already done for Spring Cache or Spring Transactions > > integrations). It must be updated and re-released only in case of broken > > backward compatibility between Spring Data versions or if the extension > > itself is updated. This process is described in the thread - [2]. > > > > > > [1] - https://github.com/apache/ignite-extensions/tree/master/modules > > [2] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20 > > > > On 18.02.2022 13:13, Maksim Timonin wrote: > > > Hi Mikhail, > > > > > >> remove extension modules that are tied to the specific Spring Data > > versions > > > - keep only a single spring-data-ext module. For now, it will contain > > code > > > for the latest Ignite Spring Data integration - > > ignite-spring-data-2.2-ext. > > > > > > I'm +1 for having a single repository for the spring-data extensions. > > But I > > > think we must not completely remove code for 2.0, 2.1 versions. I'd > > propose > > > to create separated branches in the repository for those versions, and > > put > > > tags for already released versions. > > > > > >> According to [5] 1.0 and 2.0 versions are no longer supported > > > According to this 2.2 isn't supported too, the last release was a year > > ago, > > > is it? Do we have plans to support spring-data with the latest version? > > > > > > On Fri, Feb 18, 2022 at 10:57 AM Mikhail Petrov <pmgheap....@gmail.com> > > > wrote: > > > > > >> Igniters, > > >> Currently, we have three separate modules for Ignite Spring Data > > >> integrations - [1 - 3]. Each of them depends on the specific version of > > >> the Spring Data - 1.0, 2.0, and 2.2, respectively. > > >> > > >> I propose to: > > >> 1. remove extension modules that are tied to the specific Spring Data > > >> versions - keep only a single spring-data-ext module. For now, it will > > >> contain code for the latest Ignite Spring Data integration - > > >> ignite-spring-data-2.2-ext. > > >> 2. Proceed with spring-data integration future releases as were > > >> discussed here - [6]. > > >> > > >> Motivation: > > >> 1. Almost all bug fixes or improvements for the Spring Data > > >> integration are copied multiple times for each module > > >> 2. According to [5] 1.0 and 2.0 versions are no longer supported and > > >> since the corresponding integrations were already released, we can > > >> remove them safely. > > >> 3. Some patches already neglect versions 1.0 and 2.0 - [4] > > >> > > >> > > >> WDYT? > > >> > > >> [1] - > > >> > > >> > > https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-ext > > >> [2] - > > >> > > >> > > https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-2.0-ext > > >> [3] - > > >> > > >> > > https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-2.2-ext > > >> [4] - https://github.com/apache/ignite-extensions/pull/41 > > >> [5] - > > >> > > >> > > https://mvnrepository.com/artifact/org.springframework.data/spring-data-commons > > >> [6] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20 > > >> > > >> > >
