You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Roman Puchkovskiy <ro...@gmail.com> on 2022/04/18 10:16:57 UTC

Re: [DISCUSSION] Removing extensions for obsolete Ignite Spring Data integrations.

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 <ti...@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 <pm...@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 <pm...@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
> > >>
> > >>
> >

Re: [DISCUSSION] Removing extensions for obsolete Ignite Spring Data integrations.

Posted by Roman Puchkovskiy <ro...@gmail.com>.
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&tab=buildResultsDiv&buildTypeId=IgniteExtensions_Tests_RunAllTests

пн, 18 апр. 2022 г. в 14:29, Maxim Muzafarov <mm...@apache.org>:
>
> 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
> <ro...@gmail.com> 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 <ti...@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 <pm...@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 <pm...@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
> > > > >>
> > > > >>
> > > >

Re: [DISCUSSION] Removing extensions for obsolete Ignite Spring Data integrations.

Posted by Maxim Muzafarov <mm...@apache.org>.
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
<ro...@gmail.com> 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 <ti...@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 <pm...@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 <pm...@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
> > > >>
> > > >>
> > >