I've created a PR [1] that implements the above mentioned changes
(also described in [2]).
I triggered a build on TeamCity, here is the result: [3]. Two test
tasks failed, both due to the removal of ignite-spring-data-2.0-ext
and ignite-spring-data-2.2-ext (which was renamed to just
ignite-spring-data-ext), so the changed code seems to work from the
'point of view' of the tests.
Could you please take a look at the PR?
[1] - https://github.com/apache/ignite-extensions/pull/120
[2] - https://issues.apache.org/jira/browse/IGNITE-16869
[3] -
https://ci.ignite.apache.org/viewLog.html?buildId=6533271=buildResultsDiv=IgniteExtensions_Tests_RunAllTests
пн, 18 апр. 2022 г. в 14:29, Maxim Muzafarov :
>
> Hello Roman,
>
> +1 to your suggestion.
> If you need any help with a review, please let me know.
>
> On Mon, 18 Apr 2022 at 13:17, Roman Puchkovskiy
> wrote:
> >
> > 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 :
> > >
> > > > 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
> > > 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
