You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Abe Ratnofsky <ab...@aber.io> on 2022/07/19 19:19:38 UTC

[DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Hello all,

We currently depend on Maven Ant Tasks (MAT) during build, for declaring dependencies and generating POM files from within build.xml. MAT has long been retired (no commits since maintenance in 2015), has registered CVEs in its dependencies (CVE-2017-1000487), and encourages migration to its successor, Maven Artifact Resolver Ant Tasks (MARAT). More detail in the Jira: https://issues.apache.org/jira/browse/CASSANDRA-17750

I have a PR up to remove our dependency on MAT, with discussion from David Capwell and Mick Semb Wever: https://github.com/apache/cassandra/pull/1725

There are two main items for wider discussion:

1. Is it worth addressing this CVE and retired dependency with changes to our build system, or should we suppress it?

2. Are there more alternatives to Maven Ant Tasks that should be considered, like Ivy?

My stance, summarized from the PR comments, is that a retired dependency that does not receive security updates (current CVE or not) should be replaced by a maintained project, and that the general approach in the PR (give or take minor changes to POM packaging) is the one most compatible with our current approach, and does not preclude any build system changes in the near or distant future.

Curious to hear from others.

—
Abe

Re: unsubscribe

Posted by Erick Ramirez <er...@apache.org>.
Hey, mate! Sorry to see you go. If you'd like to unsubscribe from the dev
ML, please email dev-unsubscribe@cassandra.apache.org. Cheers!

On Wed, 20 Jul 2022 at 09:11, Ben Krug via dev <de...@cassandra.apache.org>
wrote:

> unsubscribe
>

unsubscribe

Posted by Ben Krug via dev <de...@cassandra.apache.org>.
 unsubscribe

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by Derek Chen-Becker <de...@chen-becker.org>.
I guess dependency management is circular like fashion :) Are the concerns
enumerated in that ticket still valid today? It looks like the makepom
command can take a template for the POM, so that might be a way to deal
with inconsistencies?

Cheers,

Derek

On Tue, Jul 19, 2022 at 2:35 PM Brandon Williams <dr...@gmail.com> wrote:

> Ivy is actually how we got to MAT:
> https://issues.apache.org/jira/browse/CASSANDRA-2017
>
> Kind Regards,
> Brandon
>
> On Tue, Jul 19, 2022 at 3:33 PM Derek Chen-Becker <de...@chen-becker.org>
> wrote:
> >
> > Sorry, I put a comment about this in the PR before seeing this. I think
> if Ivy fits better with Ant, is more compact, and can do everything that we
> were using MAT for, then that's a reasonable path forward. I don't think
> Ivy syntax for dependencies will be foreign to anyone familiar with Maven.
> >
> > Derek
> >
> > On Tue, Jul 19, 2022 at 2:03 PM Mick Semb Wever <mc...@apache.org> wrote:
> >>
> >>
> >>
> >> Rehashing some of the aspects raised by the PR…
> >>
> >>
> >>>
> >>> 1. Is it worth addressing this CVE and retired dependency with changes
> to our build system, or should we suppress it?
> >>
> >>
> >>
> >> If we are not exposed to the CVE then it should be considered
> suppressed.
> >> While this might address (remove) the urgency of the matter, it is not
> an argument against replacing and improving a deprecated and unmaintained
> dependency.
> >>
> >>
> >>
> >>>
> >>> 2. Are there more alternatives to Maven Ant Tasks that should be
> considered, like Ivy?
> >>
> >>
> >>
> >> The question here is… If we are to replace MARAT, then *what*
> dependency framework/format do we want to work with moving forward?
> >>
> >> The choices are:
> >>  - maven
> >>  - ivy
> >>  - gradle
> >>
> >> Note this is ONLY for dependency management, and is only about the
> replacement for this section:
> https://github.com/apache/cassandra/blob/315a1a7/build.xml#L507-L873
> >>
> >> It is a requirement that whatever framework/format we choose it can
> generated into the pom(s) we publish via repository.apache.org
> >> For example maven pom files would be used directly, ivy could use the
> `makepom` command and gradle the `maven-publish` plugin.
> >>
> >> Ivy and Gradle provide more compact dependency declarations, Ivy fits
> in better with Ant, and most are familiar with Maven (and it would avoid
> the generation step).
> >>
> >> What is the best fit for us moving forward?
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > +---------------------------------------------------------------+
> > | Derek Chen-Becker                                             |
> > | GPG Key available at https://keybase.io/dchenbecker and       |
> > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> > +---------------------------------------------------------------+
> >
>


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by Brandon Williams <dr...@gmail.com>.
Ivy is actually how we got to MAT:
https://issues.apache.org/jira/browse/CASSANDRA-2017

Kind Regards,
Brandon

On Tue, Jul 19, 2022 at 3:33 PM Derek Chen-Becker <de...@chen-becker.org> wrote:
>
> Sorry, I put a comment about this in the PR before seeing this. I think if Ivy fits better with Ant, is more compact, and can do everything that we were using MAT for, then that's a reasonable path forward. I don't think Ivy syntax for dependencies will be foreign to anyone familiar with Maven.
>
> Derek
>
> On Tue, Jul 19, 2022 at 2:03 PM Mick Semb Wever <mc...@apache.org> wrote:
>>
>>
>>
>> Rehashing some of the aspects raised by the PR…
>>
>>
>>>
>>> 1. Is it worth addressing this CVE and retired dependency with changes to our build system, or should we suppress it?
>>
>>
>>
>> If we are not exposed to the CVE then it should be considered suppressed.
>> While this might address (remove) the urgency of the matter, it is not an argument against replacing and improving a deprecated and unmaintained dependency.
>>
>>
>>
>>>
>>> 2. Are there more alternatives to Maven Ant Tasks that should be considered, like Ivy?
>>
>>
>>
>> The question here is… If we are to replace MARAT, then *what* dependency framework/format do we want to work with moving forward?
>>
>> The choices are:
>>  - maven
>>  - ivy
>>  - gradle
>>
>> Note this is ONLY for dependency management, and is only about the replacement for this section: https://github.com/apache/cassandra/blob/315a1a7/build.xml#L507-L873
>>
>> It is a requirement that whatever framework/format we choose it can generated into the pom(s) we publish via repository.apache.org
>> For example maven pom files would be used directly, ivy could use the `makepom` command and gradle the `maven-publish` plugin.
>>
>> Ivy and Gradle provide more compact dependency declarations, Ivy fits in better with Ant, and most are familiar with Maven (and it would avoid the generation step).
>>
>> What is the best fit for us moving forward?
>>
>>
>>
>>
>
>
>
> --
> +---------------------------------------------------------------+
> | Derek Chen-Becker                                             |
> | GPG Key available at https://keybase.io/dchenbecker and       |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---------------------------------------------------------------+
>

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by Derek Chen-Becker <de...@chen-becker.org>.
Sorry, I put a comment about this in the PR before seeing this. I think if
Ivy fits better with Ant, is more compact, and can do everything that we
were using MAT for, then that's a reasonable path forward. I don't think
Ivy syntax for dependencies will be foreign to anyone familiar with Maven.

Derek

On Tue, Jul 19, 2022 at 2:03 PM Mick Semb Wever <mc...@apache.org> wrote:

>
>
> Rehashing some of the aspects raised by the PR…
>
>
>
>> 1. Is it worth addressing this CVE and retired dependency with changes to
>> our build system, or should we suppress it?
>>
>
>
> If we are not exposed to the CVE then it should be considered suppressed.
> While this might address (remove) the urgency of the matter, it is not an
> argument against replacing and improving a deprecated and unmaintained
> dependency.
>
>
>
>
>> 2. Are there more alternatives to Maven Ant Tasks that should be
>> considered, like Ivy?
>>
>
>
> The question here is… If we are to replace MARAT, then *what* dependency
> framework/format do we want to work with moving forward?
>
> The choices are:
>  - maven
>  - ivy
>  - gradle
>
> Note this is ONLY for dependency management, and is only about the
> replacement for this section:
> https://github.com/apache/cassandra/blob/315a1a7/build.xml#L507-L873
>
> It is a requirement that whatever framework/format we choose it can
> generated into the pom(s) we publish via repository.apache.org
> For example maven pom files would be used directly, ivy could use the
> `makepom` command and gradle the `maven-publish` plugin.
>
> Ivy and Gradle provide more compact dependency declarations, Ivy fits in
> better with Ant, and most are familiar with Maven (and it would avoid the
> generation step).
>
> What is the best fit for us moving forward?
>
>
>
>
>


-- 
+---------------------------------------------------------------+
| Derek Chen-Becker                                             |
| GPG Key available at https://keybase.io/dchenbecker and       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---------------------------------------------------------------+

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by emmanuel warreng <em...@gmail.com>.
Unsubscribe

On Tue, Jul 19, 2022, 22:03 Mick Semb Wever <mc...@apache.org> wrote:

>
>
> Rehashing some of the aspects raised by the PR…
>
>
>
>> 1. Is it worth addressing this CVE and retired dependency with changes to
>> our build system, or should we suppress it?
>>
>
>
> If we are not exposed to the CVE then it should be considered suppressed.
> While this might address (remove) the urgency of the matter, it is not an
> argument against replacing and improving a deprecated and unmaintained
> dependency.
>
>
>
>
>> 2. Are there more alternatives to Maven Ant Tasks that should be
>> considered, like Ivy?
>>
>
>
> The question here is… If we are to replace MARAT, then *what* dependency
> framework/format do we want to work with moving forward?
>
> The choices are:
>  - maven
>  - ivy
>  - gradle
>
> Note this is ONLY for dependency management, and is only about the
> replacement for this section:
> https://github.com/apache/cassandra/blob/315a1a7/build.xml#L507-L873
>
> It is a requirement that whatever framework/format we choose it can
> generated into the pom(s) we publish via repository.apache.org
> For example maven pom files would be used directly, ivy could use the
> `makepom` command and gradle the `maven-publish` plugin.
>
> Ivy and Gradle provide more compact dependency declarations, Ivy fits in
> better with Ant, and most are familiar with Maven (and it would avoid the
> generation step).
>
> What is the best fit for us moving forward?
>
>
>
>
>

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by Mick Semb Wever <mc...@apache.org>.
Rehashing some of the aspects raised by the PR…



> 1. Is it worth addressing this CVE and retired dependency with changes to
> our build system, or should we suppress it?
>


If we are not exposed to the CVE then it should be considered suppressed.
While this might address (remove) the urgency of the matter, it is not an
argument against replacing and improving a deprecated and unmaintained
dependency.




> 2. Are there more alternatives to Maven Ant Tasks that should be
> considered, like Ivy?
>


The question here is… If we are to replace MARAT, then *what* dependency
framework/format do we want to work with moving forward?

The choices are:
 - maven
 - ivy
 - gradle

Note this is ONLY for dependency management, and is only about the
replacement for this section:
https://github.com/apache/cassandra/blob/315a1a7/build.xml#L507-L873

It is a requirement that whatever framework/format we choose it can
generated into the pom(s) we publish via repository.apache.org
For example maven pom files would be used directly, ivy could use the
`makepom` command and gradle the `maven-publish` plugin.

Ivy and Gradle provide more compact dependency declarations, Ivy fits in
better with Ant, and most are familiar with Maven (and it would avoid the
generation step).

What is the best fit for us moving forward?

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by Abe Ratnofsky <ab...@aber.io>.
Most of the discussion has happened in the PR: https://github.com/apache/cassandra/pull/1725

Leaving this thread open over the weekend to gather input.

> On Jul 20, 2022, at 10:40 AM, emmanuel warreng <em...@gmail.com> wrote:
> 
> Unsubscribe
> 
> On Tue, Jul 19, 2022, 21:20 Abe Ratnofsky <abe@aber.io <ma...@aber.io>> wrote:
> Hello all,
> 
> We currently depend on Maven Ant Tasks (MAT) during build, for declaring dependencies and generating POM files from within build.xml. MAT has long been retired (no commits since maintenance in 2015), has registered CVEs in its dependencies (CVE-2017-1000487), and encourages migration to its successor, Maven Artifact Resolver Ant Tasks (MARAT). More detail in the Jira: https://issues.apache.org/jira/browse/CASSANDRA-17750 <https://issues.apache.org/jira/browse/CASSANDRA-17750>
> 
> I have a PR up to remove our dependency on MAT, with discussion from David Capwell and Mick Semb Wever: https://github.com/apache/cassandra/pull/1725 <https://github.com/apache/cassandra/pull/1725>
> 
> There are two main items for wider discussion:
> 
> 1. Is it worth addressing this CVE and retired dependency with changes to our build system, or should we suppress it?
> 
> 2. Are there more alternatives to Maven Ant Tasks that should be considered, like Ivy?
> 
> My stance, summarized from the PR comments, is that a retired dependency that does not receive security updates (current CVE or not) should be replaced by a maintained project, and that the general approach in the PR (give or take minor changes to POM packaging) is the one most compatible with our current approach, and does not preclude any build system changes in the near or distant future.
> 
> Curious to hear from others.
> 
> —
> Abe


Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Posted by emmanuel warreng <em...@gmail.com>.
Unsubscribe

On Tue, Jul 19, 2022, 21:20 Abe Ratnofsky <ab...@aber.io> wrote:

> Hello all,
>
> We currently depend on Maven Ant Tasks (MAT) during build, for declaring
> dependencies and generating POM files from within build.xml. MAT has long
> been retired (no commits since maintenance in 2015), has registered CVEs in
> its dependencies (CVE-2017-1000487), and encourages migration to its
> successor, Maven Artifact Resolver Ant Tasks (MARAT). More detail in the
> Jira: https://issues.apache.org/jira/browse/CASSANDRA-17750
>
> I have a PR up to remove our dependency on MAT, with discussion from David
> Capwell and Mick Semb Wever: https://github.com/apache/cassandra/pull/1725
>
> There are two main items for wider discussion:
>
> 1. Is it worth addressing this CVE and retired dependency with changes to
> our build system, or should we suppress it?
>
> 2. Are there more alternatives to Maven Ant Tasks that should be
> considered, like Ivy?
>
> My stance, summarized from the PR comments, is that a retired dependency
> that does not receive security updates (current CVE or not) should be
> replaced by a maintained project, and that the general approach in the PR
> (give or take minor changes to POM packaging) is the one most compatible
> with our current approach, and does not preclude any build system changes
> in the near or distant future.
>
> Curious to hear from others.
>
> —
> Abe