Re: Maven Dependency Plugin - Log4j vulnerabilities

[Juraj Veverka]

Hi David

Just for clarification: we are not relying on the maven dependency plugin
at runtime. Our runtime is perfectly clear of log4j vulnerabilities.
The problem is that our security scanners are scanning gitlab runner nodes
(virtual machines on which we compile and package our application) and
log4j vulnerability is found there.

Kind regards
Juraj Veverka

On Mon, Feb 28, 2022 at 1:32 PM Juraj Veverka 
wrote:

> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet 
> wrote:
>
>> Where I work we decided to address log4j vulnerabilities only for
>> components directly used by the application and actually performing logging.
>> We ignored transitive dependencies and maven plug-ins.
>> I’m curious about this use case from Venu though, what application would
>> rely on the maven dependency plugin at runtime? Does it mean you’re pulling
>> maven dependencies after application startup?
>>
>> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
>> wrote:
>> >
>> > Hi,
>> >
>> > Please provide more information, like plugin, mven, os version.
>> >
>> > We also need an example project which reproduces your issue.
>> > When we can't reproduce we can't help.
>> >
>> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
>> >  napisał(a):
>> >
>> >> Hi team,
>> >>
>> >> Can I expect any response?  Is this the right email address for my
>> >> question?
>> >>
>> >> Thanks,
>> >> Venu
>> >>
>> >>
>> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
>> >>> jaladi.venumad...@verizon.com> wrote:
>> >>>
>> >>> Hi team,
>> >>>
>> >>> We are using the Maven Dependency Plugin in one of our projects and
>> our
>> >>> scanning tools are showing multiple vulnerabilities related to Log4j
>> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
>> >>> CVE-2022-23307 and CVE-2021-4104).
>> >>>
>> >>> We would  like to know if there are any plans to release a newer
>> version
>> >>> of Maven Dependency Plugin with the fixes of these
>> >>> vulnerabilities(referring to the latest version of Log4j libraries).
>> If
>> >>> so, is there any planned date for this release?
>> >>>
>> >>> Please let us know any any more information is required.
>> >>>
>> >>> Thanks,
>> >>> Venu
>> >>>
>> >>
>> >
>> >
>> > --
>> > Sławomir Jaranowski
>>
>>
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm
>
>
>

-- 

Best Regards


--

Juraj Veverka  | Solution Design Architect

M +421 917 521 285

www.globallogic.sk  

   [image: GLTwitter]





http://www.globallogic.com/Disclaimer.htm

JDK 18 Release Candidate builds & JDK 19 Early-Access builds

[David Delabassee]

Robert, All,

The Release Candidates of JDK 18 have been released [1]. At this stage, 
only P1 issues will be evaluated [2]. And with the JDK 18 General 
Availability sets for March 22nd, it is now time to shift the focus to 
JDK 19. I'd like to thank those of you who have already provided 
feedback on the early Early Builds of JDK 19. Feedback is always 
extremely useful, even more, when it comes early in the development cycle.


[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html

[2] https://openjdk.java.net/jeps/3


## JDK 18 Release Candidate

The Release Candidate builds of JDK 18 are now available [3], and are 
provided under the GNU General Public License v2, with the Classpath 
Exception. The Release Notes are available here [4].


[3] https://jdk.java.net/18/
[4] https://jdk.java.net/18/release-notes


## JDK 19 Early-Access builds

JDK 19 Early-Access builds 11 are now available [5], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [6].


[5] https://jdk.java.net/19/
[6] https://jdk.java.net/19/release-notes

Recent changes that maybe of interest:

* JDK-8278067: Make HttpURLConnection default keep alive timeout 
configurable
* JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if 
caller is null

* JDK-8282279: Interpret case-insensitive string locale independently
* JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats
* JDK-5041655: (ch) FileLock: negative param and overflow issues
* JDK-8255266: Update Public Suffix List to 3c213aa
* JDK-8280958: G1/Parallel: Unify marking code structure
* JDK-8072070: Improve interpreter stack banging
* JDK-8277175: Add a parallel multiply method to BigInteger
* JDK-8278947: Support for array constants in constant table
* JDK-8281462: Annotation toString output for enum not reusable for 
source input

* JDK-8281175: Add a -providerPath option to jarsigner
* JDK-8277795: ldap connection timeout not honoured under contention
* JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos
* JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts
* JDK-8272984: javadoc support for reproducible builds
* JDK-8272317: jstatd has dependency on Security Manager which needs to 
be removed



## New Project Loom Early-Access builds

Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available 
[7] with the related Javadoc [8].


These EA builds are based on JDK 19 (jdk-19+9). In those builds, the 
APIs for Structured Concurrency and Scope Locals have been moved into 
the `jdk.incubator.concurrent` incubator module. Note that the module 
name may change later. To use those APIs, simply use `--add-modules 
jdk.incubator.concurrent` at compile and runtime.


Those EA builds are provided under the GNU General Public License, 
version 2, with the Classpath Exception and are produced for the purpose 
of gathering feedback. Use for any other purpose is at your own risk. 
Proper feedback should be sent to the `loom-dev` mailing list [9].


[7] https://jdk.java.net/loom/
[8] https://download.java.net/java/early_access/loom/docs/api/
[9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev


## Topics of Interest

* JDK 18 - Card Table Card Size Shenanigans 
https://tschatzl.github.io/2022/02/15/card-table-card-size.html
* Compiled & Tested Code In Javadoc - Inside Java Newscast #20 
https://inside.java/2022/02/10/insidejava-newscast-020/
* New candidate JEP: 423: Region Pinning for G1 
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html
* Refactoring Java 8 code with Java 17 new features - JEP Café #9 
https://inside.java/2022/02/01/jepcafe9/




As always, let us know if you find any issues while testing your 
projects on the latest JDK Early Access builds. Thanks for your support!


--David


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

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Enrico Olivelli]

Juraj,
I have run this command on your reproducer and in "tmp" I cannot find
log4j versions other then 2.17.1

mvn clean install -X -Dmaven.repo.local=tmp > out.txt

Enrico

Il giorno lun 28 feb 2022 alle ore 13:52 Juraj Veverka
 ha scritto:
>
> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:
>
> > Where I work we decided to address log4j vulnerabilities only for
> > components directly used by the application and actually performing logging.
> > We ignored transitive dependencies and maven plug-ins.
> > I’m curious about this use case from Venu though, what application would
> > rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> > maven dependencies after application startup?
> >
> > > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> > wrote:
> > >
> > > Hi,
> > >
> > > Please provide more information, like plugin, mven, os version.
> > >
> > > We also need an example project which reproduces your issue.
> > > When we can't reproduce we can't help.
> > >
> > > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> > >  napisał(a):
> > >
> > >> Hi team,
> > >>
> > >> Can I expect any response?  Is this the right email address for my
> > >> question?
> > >>
> > >> Thanks,
> > >> Venu
> > >>
> > >>
> > >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> > >>> jaladi.venumad...@verizon.com> wrote:
> > >>>
> > >>> Hi team,
> > >>>
> > >>> We are using the Maven Dependency Plugin in one of our projects and our
> > >>> scanning tools are showing multiple vulnerabilities related to Log4j
> > >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > >>> CVE-2022-23307 and CVE-2021-4104).
> > >>>
> > >>> We would  like to know if there are any plans to release a newer
> > version
> > >>> of Maven Dependency Plugin with the fixes of these
> > >>> vulnerabilities(referring to the latest version of Log4j libraries).
> > If
> > >>> so, is there any planned date for this release?
> > >>>
> > >>> Please let us know any any more information is required.
> > >>>
> > >>> Thanks,
> > >>> Venu
> > >>>
> > >>
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm

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

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Juraj Veverka]

Hi David

Many thanks for your email, I really appreciate your reply. This is an
isolated example of the problem.
https://github.com/jveverka/mvn-dependency-log4j
You can find all repro steps there. In case of any questions, feel free
to contact me.

Kind regards
Juraj Veverka



On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:

> Where I work we decided to address log4j vulnerabilities only for
> components directly used by the application and actually performing logging.
> We ignored transitive dependencies and maven plug-ins.
> I’m curious about this use case from Venu though, what application would
> rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> maven dependencies after application startup?
>
> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> wrote:
> >
> > Hi,
> >
> > Please provide more information, like plugin, mven, os version.
> >
> > We also need an example project which reproduces your issue.
> > When we can't reproduce we can't help.
> >
> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> >  napisał(a):
> >
> >> Hi team,
> >>
> >> Can I expect any response?  Is this the right email address for my
> >> question?
> >>
> >> Thanks,
> >> Venu
> >>
> >>
> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> >>> jaladi.venumad...@verizon.com> wrote:
> >>>
> >>> Hi team,
> >>>
> >>> We are using the Maven Dependency Plugin in one of our projects and our
> >>> scanning tools are showing multiple vulnerabilities related to Log4j
> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> >>> CVE-2022-23307 and CVE-2021-4104).
> >>>
> >>> We would  like to know if there are any plans to release a newer
> version
> >>> of Maven Dependency Plugin with the fixes of these
> >>> vulnerabilities(referring to the latest version of Log4j libraries).
> If
> >>> so, is there any planned date for this release?
> >>>
> >>> Please let us know any any more information is required.
> >>>
> >>> Thanks,
> >>> Venu
> >>>
> >>
> >
> >
> > --
> > Sławomir Jaranowski
>
>

-- 

Best Regards


--

Juraj Veverka  | Solution Design Architect

M +421 917 521 285

www.globallogic.sk  

   [image: GLTwitter]





http://www.globallogic.com/Disclaimer.htm

Re: Maven Dependency Plugin - Log4j vulnerabilities

[David Milet]

Where I work we decided to address log4j vulnerabilities only for components 
directly used by the application and actually performing logging.
We ignored transitive dependencies and maven plug-ins.
I’m curious about this use case from Venu though, what application would rely 
on the maven dependency plugin at runtime? Does it mean you’re pulling maven 
dependencies after application startup? 

> On Feb 28, 2022, at 03:30, Slawomir Jaranowski  wrote:
> 
> Hi,
> 
> Please provide more information, like plugin, mven, os version.
> 
> We also need an example project which reproduces your issue.
> When we can't reproduce we can't help.
> 
> pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
>  napisał(a):
> 
>> Hi team,
>> 
>> Can I expect any response?  Is this the right email address for my
>> question?
>> 
>> Thanks,
>> Venu
>> 
>> 
>>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
>>> jaladi.venumad...@verizon.com> wrote:
>>> 
>>> Hi team,
>>> 
>>> We are using the Maven Dependency Plugin in one of our projects and our
>>> scanning tools are showing multiple vulnerabilities related to Log4j
>>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
>>> CVE-2022-23307 and CVE-2021-4104).
>>> 
>>> We would  like to know if there are any plans to release a newer version
>>> of Maven Dependency Plugin with the fixes of these
>>> vulnerabilities(referring to the latest version of Log4j libraries).  If
>>> so, is there any planned date for this release?
>>> 
>>> Please let us know any any more information is required.
>>> 
>>> Thanks,
>>> Venu
>>> 
>> 
> 
> 
> -- 
> Sławomir Jaranowski

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

Re: Review of used reports for Maven project sites.

[Olivier Lamy]

FYI as Im testing a few more projects with this ci reporting enabled.
POC has been moved here
https://ci-maven.apache.org/job/Maven/job/ci-reporting-test/job/maven-compiler-plugin/job/ci-reporting/
each project I'm trying will have a branch called ci-reporting.
started a PR as well to move the profile configuration to maven parent pom (
https://github.com/apache/maven-parent/pull/56)
And please no comments on 99-SNAPSHOT it's only for testing purposes now :P




On Sun, 27 Feb 2022 at 10:46, Olivier Lamy  wrote:

> Thanks for the PRs.
> I'd like to start a discussion rather than some comments in PRs lost in
> the middle of gh notification flood.
> I have started some POC including more "live" reporting in Jenkins (by
> live I mean this could be at least for every commit to master).
> Perso, I'm not reading some reports from the site produced at release time
> because it's simply too late as nothing can be done to improve anything.
> Who is really reading those reports after a release has been made?
> Code analysis is interesting when we develop/change the code to improve it
> (i.e monitoring change of master branch) but once release is done do we
> really care?
> Well this can be a long discussion :)
> Anyway the POC now includes reports such jacoco somes static analysis
> (pmd, checkstyle, spotbugs, errorprone) and some logs parsing (maven
> warning, compiler warnings)
> See here
> https://ci-maven.apache.org/job/Maven/job/maven-compiler-plugin-test-olamy/job/ci-reporting/15/linux-jdk11/
>
> such reports do not fail the build and can show improvement of the master
> branch.
> It's a POC only available now in a maven-compiler-plugin
> branch ci-reporting and the common jenkins build with this PR (
> https://github.com/apache/maven-jenkins-lib/pull/3)
> if someone need some more reports more formats are available here
> https://github.com/jenkinsci/analysis-model/blob/master/SUPPORTED-FORMATS.md
>
>
> comments welcome.
>
>
>
> On Sat, 26 Feb 2022 at 03:41, Slawomir Jaranowski 
> wrote:
>
>> Hi,
>>
>> I've created a few PRs for removing some reports from Maven site. [1]
>>
>> I think that such reports do not bring any useful information for project
>> documentations, but have influence to site build time.
>>
>> [1] https://github.com/apache/maven-parent/pulls
>>
>>
>> pt., 25 lut 2022 o 03:11 Olivier Lamy  napisał(a):
>>
>> > Hi,
>> >
>> > On Fri, 25 Feb 2022 at 07:57, Slawomir Jaranowski <
>> s.jaranow...@gmail.com>
>> > wrote:
>> >
>> > > Hi
>> > > In next version of Maven parent
>> > >  - detectLinks from javadoc configurations was removed, so javadoc
>> will
>> > not
>> > > download remote resource, it was fails many times in this case
>> > >  - findbugs was removed - it also took a lot of time
>> > >
>> > > My proposition is to remove from reports:
>> > >   - surefire
>> > >   - checkstyle
>> > >   - pmd
>> > >   - taglist
>> > >   - invoker
>> > >   and finally - jxr
>> > >
>> > > chekstyle is used during build,
>> > > if we want to use pmd should be included in build
>> > > any other tests result are reported on jenkins for each build, I don't
>> > see
>> > > benefit of such in documentations
>> > >
>> >
>> > I tend to agree to remove reports which are already part of the build
>> and
>> > fail the build in case of issues (such checkstyle, surefire, invoker).
>> > Because at the end reports are just empty and finally do not provide
>> much
>> > more interesting information.
>> > What about having those reports in Jenkins (for at least only one
>> > combination).
>> > But which one? Jenkins reporting can support a lot of tools
>> >
>> >
>> https://github.com/jenkinsci/analysis-model/blob/master/SUPPORTED-FORMATS.md
>> > I feel sometimes some reports are generating some false negative
>> warnings,
>> > But at least it will be here if someone wants to have a look but would
>> not
>> > fail a normal build and not make extra noise
>> > Not sure which tools could be interesting? spotbugs, compiler warnings,
>> > what else?
>> >
>> >
>> >
>> > >
>> > > and of course I can change GH action to build site only on one node
>> > >
>> >
>> > agree on that maybe for only 1 combination such linux/jdk 1.8/maven last
>> > version?
>> >
>> >
>> > >
>> > > czw., 24 lut 2022 o 22:49 Tamás Cservenák 
>> > > napisał(a):
>> > >
>> > > > Olivier,
>> > > >
>> > > > please remove all the Jenkins checks from all of the Maven builds
>> you
>> > > added
>> > > > without asking anyone about adding it.
>> > > > The release manager should ensure beforehand it is all ok, if not,
>> try
>> > to
>> > > > fix it, if the issue is bigger, still can decide to rollback the
>> > change.
>> > > >
>> > > > Thanks
>> > > > T
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Feb 24, 2022 at 10:14 PM Tamás Cservenák <
>> ta...@cservenak.net>
>> > > > wrote:
>> > > >
>> > > > > Building javadoc is slow and very fragile (fetches remote
>> resources,
>> > > > chews
>> > > > > on stuff etc).
>> > > > > Why not have a savvy release manager ensuring it is 

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Slawomir Jaranowski]

Hi,

Please provide more information, like plugin, mven, os version.

We also need an example project which reproduces your issue.
When we can't reproduce we can't help.

pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
 napisał(a):

> Hi team,
>
> Can I expect any response?  Is this the right email address for my
> question?
>
> Thanks,
> Venu
>
>
> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> jaladi.venumad...@verizon.com> wrote:
>
> > Hi team,
> >
> > We are using the Maven Dependency Plugin in one of our projects and our
> > scanning tools are showing multiple vulnerabilities related to Log4j
> > (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > CVE-2022-23307 and CVE-2021-4104).
> >
> > We would  like to know if there are any plans to release a newer version
> > of Maven Dependency Plugin with the fixes of these
> > vulnerabilities(referring to the latest version of Log4j libraries).  If
> > so, is there any planned date for this release?
> >
> > Please let us know any any more information is required.
> >
> > Thanks,
> > Venu
> >
>


-- 
Sławomir Jaranowski