Re: Ivy-2.5.0

[Jaikiran Pai]

Maarten, I just pushed a change to Ivy upstream to not force existing 
implementations of this URLHandler to understand timeout constraints and 
yet have the feature available for other implementations. When you get a 
chance, can you please try the IvyIdea plugin build/test with the latest 
Ivy and see if it solves the issue?


-Jaikiran


On 09/01/18 5:53 PM, Maarten Coene wrote:

The change to the URLHandler class (TimoutConstraint) is also backwards 
incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an 
extension of AbstractURLHandler.
I didn't look into it yet, maybe it can be changed to be more backwards 
compatible?

kind regards,Maarten

   Van: Gintautas Grigelionis 
  Aan: Ant Developers List 
  Verzonden: dinsdag 9 januari 9:45 2018
  Onderwerp: Re: Ivy-2.5.0

2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) :



What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
PR-55/PR-60)? If you fine with merging (eventually adjusting the
contents of SVG), let's do it.

I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?


I hope I addressed all points now.



Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
evaluated by reporters, but nobody responded because the issues are so
old.
I would rather close the issues and a open a new issue if needed. I

No. It's just a matter of prioritization by us.




added test cases for every issue highlighting the specific parts of the
problem and I can write up separately on the design problem with
permitting the same attributes on different elements with recursive
inheritance or using the same attribute name with different semantics
depending on the element (perhaps in Confluence? or Github wiki?).

Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.


The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.

Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.

So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.

Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).

I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.



My opinion on PR-57 is that it addresses another design problem in a
similarly good-enough fashion. We can handle this like Ant and have a
Java
7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
The question is, whether that makes 2.5.x more interesting and is worth
the extra work?

I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.

I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method
   -- no changes in semantics, but only in method declaration
(array->collection, generics)
   -- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and
adding that new method
   (could be 'inlined' in later Ivy version).

I followed the mail thread https://www.mail-archive.com/
dev@ant.apache.org/msg46002.html and found another problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).

Maybe we should not include this PR into an Ivy-2.5.0 release but instead
move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
backwards incompatible way.


PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.

We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.

Gintas

 

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Matt Sicker]

After 2.8.2, there's a class whitelist used for deserializing data in the
receiver.

On 7 February 2018 at 12:19, Gintautas Grigelionis 
wrote:

> Sorry, could you please clarify whether there different aspects pertaining
> to 1.x and 2.x up to and after 2.8.2?
>
> Thanks, Gintas
>
> 2018-02-07 19:10 GMT+01:00 Matt Sicker :
>
> > Based on that version, this is related to using Java serialization for
> > logs. The general workaround here is to use a different format like JSON
> > instead to avoid the vulnerability entirely.
> >
> > On 7 February 2018 at 12:03, Gintautas Grigelionis <
> > g.grigelio...@gmail.com>
> > wrote:
> >
> > > Exactly, what I meant is that it's worth pointing out that not even all
> > > versions of log4j 2.x are safe.
> > >
> > > Gintas
> > >
> > > 2018-02-07 18:18 GMT+01:00 Stefan Bodewig :
> > >
> > > > On 2018-02-07, Gintautas Grigelionis wrote:
> > > >
> > > > > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not
> > > only
> > > > > Log4j 1.x issue. Did I miss something?
> > > >
> > > > The subject is how it has been reported to us.
> > > >
> > > > Prior to the latest releases you have not been able to use log4j2 so
> > > > there is no reason to talk about those versions. The recommended
> > > > mitigation of "don't use Log4JListener or use the log4j2-bridge" is
> > > > correct, one might add "of a log4j 2.x version that is not vulnerable
> > to
> > > > the attack".
> > > >
> > > > Stefan
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > > > For additional commands, e-mail: dev-h...@ant.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Gintautas Grigelionis]

Sorry, could you please clarify whether there different aspects pertaining
to 1.x and 2.x up to and after 2.8.2?

Thanks, Gintas

2018-02-07 19:10 GMT+01:00 Matt Sicker :

> Based on that version, this is related to using Java serialization for
> logs. The general workaround here is to use a different format like JSON
> instead to avoid the vulnerability entirely.
>
> On 7 February 2018 at 12:03, Gintautas Grigelionis <
> g.grigelio...@gmail.com>
> wrote:
>
> > Exactly, what I meant is that it's worth pointing out that not even all
> > versions of log4j 2.x are safe.
> >
> > Gintas
> >
> > 2018-02-07 18:18 GMT+01:00 Stefan Bodewig :
> >
> > > On 2018-02-07, Gintautas Grigelionis wrote:
> > >
> > > > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not
> > only
> > > > Log4j 1.x issue. Did I miss something?
> > >
> > > The subject is how it has been reported to us.
> > >
> > > Prior to the latest releases you have not been able to use log4j2 so
> > > there is no reason to talk about those versions. The recommended
> > > mitigation of "don't use Log4JListener or use the log4j2-bridge" is
> > > correct, one might add "of a log4j 2.x version that is not vulnerable
> to
> > > the attack".
> > >
> > > Stefan
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > > For additional commands, e-mail: dev-h...@ant.apache.org
> > >
> > >
> >
>
>
>
> --
> Matt Sicker 
>

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

[Gintautas Grigelionis]

2018-02-07 18:25 GMT+01:00 Stefan Bodewig :

>
> Maybe it will be easier to digest if we start at a higher level of what
> needs to be changed. I don't think moving classes so we don't have any
> split packages anymore will be enough.
>
> I'd expect we'd need to replace all code that deals with classloaders
> and replace it with ServiceLoaders if we want to avoid complex startup
> scenarios for example. Given there is no interface or base class tasks
> or types must implement this may again force us to change this model. Or
> maybe I'm just wrong.
>
> If we want a broader audience we may want to change the subject :-)
>

I believe that the primary problem is that of classloaders behaving
differently in presence of the module path.
ServiceLoaders is a different problem, my understanding is that it could be
an alternative to CDI (which currently is Java EE/EE4J).

Gintas

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Matt Sicker]

Based on that version, this is related to using Java serialization for
logs. The general workaround here is to use a different format like JSON
instead to avoid the vulnerability entirely.

On 7 February 2018 at 12:03, Gintautas Grigelionis 
wrote:

> Exactly, what I meant is that it's worth pointing out that not even all
> versions of log4j 2.x are safe.
>
> Gintas
>
> 2018-02-07 18:18 GMT+01:00 Stefan Bodewig :
>
> > On 2018-02-07, Gintautas Grigelionis wrote:
> >
> > > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not
> only
> > > Log4j 1.x issue. Did I miss something?
> >
> > The subject is how it has been reported to us.
> >
> > Prior to the latest releases you have not been able to use log4j2 so
> > there is no reason to talk about those versions. The recommended
> > mitigation of "don't use Log4JListener or use the log4j2-bridge" is
> > correct, one might add "of a log4j 2.x version that is not vulnerable to
> > the attack".
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Gintautas Grigelionis]

Exactly, what I meant is that it's worth pointing out that not even all
versions of log4j 2.x are safe.

Gintas

2018-02-07 18:18 GMT+01:00 Stefan Bodewig :

> On 2018-02-07, Gintautas Grigelionis wrote:
>
> > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not only
> > Log4j 1.x issue. Did I miss something?
>
> The subject is how it has been reported to us.
>
> Prior to the latest releases you have not been able to use log4j2 so
> there is no reason to talk about those versions. The recommended
> mitigation of "don't use Log4JListener or use the log4j2-bridge" is
> correct, one might add "of a log4j 2.x version that is not vulnerable to
> the attack".
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

[Stefan Bodewig]

On 2018-02-07, Gintautas Grigelionis wrote:

> 2018-02-07 11:44 GMT+01:00 Stefan Bodewig :

>> My fear is that if the classpath world stops working then a completely
>> different version of Ant will be required. A version that has to break
>> backwards compatibility in many ways. I'd appreciate anybody trying to
>> assess what would need to change in a pure module world, I know I cannot
>> be the one.

>> Ant plays well with the modularized JDK, we verified that in late 2016
>> before the rules were relaxed in Java9. Turning Ant into a "modular"
>> application in the sense of Java9 modules is a completely different can
>> of worms.

>  I'd like to peek into that can... would you be willing to revise a
> proposal of what classes could be moved around and/or deprecated to
> start with?

Maybe it will be easier to digest if we start at a higher level of what
needs to be changed. I don't think moving classes so we don't have any
split packages anymore will be enough.

I'd expect we'd need to replace all code that deals with classloaders
and replace it with ServiceLoaders if we want to avoid complex startup
scenarios for example. Given there is no interface or base class tasks
or types must implement this may again force us to change this model. Or
maybe I'm just wrong.

If we want a broader audience we may want to change the subject :-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Stefan Bodewig]

On 2018-02-07, Gintautas Grigelionis wrote:

> The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not only
> Log4j 1.x issue. Did I miss something?

The subject is how it has been reported to us.

Prior to the latest releases you have not been able to use log4j2 so
there is no reason to talk about those versions. The recommended
mitigation of "don't use Log4JListener or use the log4j2-bridge" is
correct, one might add "of a log4j 2.x version that is not vulnerable to
the attack".

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[Gintautas Grigelionis]

The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not only
Log4j 1.x issue. Did I miss something?

Gintas

2018-02-07 8:11 GMT+01:00 Jan Matèrne (jhm) :

> CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security
> vulnerability
>
>
>
> Severity: low
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
>
>   Apache Ant 1.9.0 - 1.9.9
>
>   Apache Ant 1.10.0 - 1.10.1
>
>   The unsupported Apache Ant 1.8 and lower versions are also affected.
>
> Description:
>
>   When using Apache Ants Log4jListener there could be a security issue with
> the
>
>   underlying Apache Log4j library in version 1.x.
>
>   Please note that Log4j 1.x has reached its end of life and is no longer
> maintained.
>
>   For details about migrating away from Log4j 1.x please consult with the
> Apache Log4j team.
>
> Mitigation:
>
>   Users should not use the Log4JListener or use the log4j2-bridge.
>
>   (Using the bridge requires Ant 1.9.10+ or Ant 1.10.2+.)
>
> Credit:
>
>   This issue was discovered by Wade Schwarz of Oracle.
>
>
>
>
>
> -Jan Matèrne
>
> on behalf of the Apache Ant PMC
>
>

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

[Gintautas Grigelionis]

2018-02-07 11:44 GMT+01:00 Stefan Bodewig :

> On 2018-02-06, Gintautas Grigelionis wrote:
>
> > 2018-02-06 11:05 GMT+01:00 Stefan Bodewig :
>
> >> If the taskdef/typedef implementation classes are loaded via a module
> >> path and a custom task lives on the CLASSPATH will taskdef be able to
> >> load it at all?
>
> > Anything on the CLASSPATH is in the unnamed module.
>
> I know. :-)
>
> > The worst that can happen is the situation where a package split between
> > module path and classpath.
> > That's what --patch-module is for.
>
> Or where a custom task lives inside of a module itself and you need to
> add an import to that module to Ant. How do you enforce that from inside
> the build file where the taskdef is written? Do you tell users of your
> task to always start with ANT_OPTS=... or provide a wrapper script?
>

Well, that's the kind of situation that a modularised Ant would address.
My starting question is "what would happen if (parts of) Ant were moved to
the module path?"

All I'm saying is that we need to try out a bunch of use cases to see
> what works and what doesn't. What users could expect of a modularized
> version of Ant and what exactly the benefit for users is going to be.
>
> Personally I don't expect the "good old classpath world" to disappear
> any time soon, but I've been wrong so many times ...
>
> > Modules is the way to take back control.
>
> Of the JDK. I really don't believe it helps writers of build tools in
> any way :-)
>

I'm tending to give JPMS a benefit of doubt :-)


> My fear is that if the classpath world stops working then a completely
> different version of Ant will be required. A version that has to break
> backwards compatibility in many ways. I'd appreciate anybody trying to
> assess what would need to change in a pure module world, I know I cannot
> be the one.
>
> Ant plays well with the modularized JDK, we verified that in late 2016
> before the rules were relaxed in Java9. Turning Ant into a "modular"
> application in the sense of Java9 modules is a completely different can
> of worms.
>

 I'd like to peek into that can... would you be willing to revise a
proposal of
 what classes could be moved around and/or deprecated to start with?

Gintas

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

[Stefan Bodewig]

On 2018-02-06, Gintautas Grigelionis wrote:

> 2018-02-06 11:05 GMT+01:00 Stefan Bodewig :

>> If the taskdef/typedef implementation classes are loaded via a module
>> path and a custom task lives on the CLASSPATH will taskdef be able to
>> load it at all?

> Anything on the CLASSPATH is in the unnamed module.

I know. :-)

> The worst that can happen is the situation where a package split between
> module path and classpath.
> That's what --patch-module is for.

Or where a custom task lives inside of a module itself and you need to
add an import to that module to Ant. How do you enforce that from inside
the build file where the taskdef is written? Do you tell users of your
task to always start with ANT_OPTS=... or provide a wrapper script?

All I'm saying is that we need to try out a bunch of use cases to see
what works and what doesn't. What users could expect of a modularized
version of Ant and what exactly the benefit for users is going to be.

Personally I don't expect the "good old classpath world" to disappear
any time soon, but I've been wrong so many times ...

> Modules is the way to take back control.

Of the JDK. I really don't believe it helps writers of build tools in
any way :-)

> There are switches in Java 9 to enable access.  We should rather be
> doing now when JRE is still lenient. Who knows what to expect from
> Java 11 LTS (6 months from now)?

My fear is that if the classpath world stops working then a completely
different version of Ant will be required. A version that has to break
backwards compatibility in many ways. I'd appreciate anybody trying to
assess what would need to change in a pure module world, I know I cannot
be the one.

Ant plays well with the modularized JDK, we verified that in late 2016
before the rules were relaxed in Java9. Turning Ant into a "modular"
application in the sense of Java9 modules is a completely different can
of worms.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org