Re: [VOTE] Release log4net 2.0.14

[Dominik Psenner]

Hi Davyd,

I checked the changes since 2.0.13 and it looks good to me. Have you also
updated the log4net site? I would like to verify that the log4net website
looks good in staging.

Cheers
Dominik

On Thu, 16 Dec 2021 at 15:09, Davyd McColl 
wrote:

> Hi all
>
> I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
> pre-release page at
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
>
> I have updated staging docs and I _think_ I've done the right thing with
> respect to getting binaries and source up to the dev repo at
> https://dist.apache.org/repos/dist/dev/logging, but the download links on
> the staging docs point to the release download area, so I'm not sure if I
> should rather upload there so that staging documentation "works as
> expected" for the vote to continue.
>
> Thanks Ralph for assisting me in being able to uplodate artifacts myself.
> Much appreciated.
>
> -d



-- 
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Dominik

The staging site is updated. Really only release notes and download links 
changed - no api changes, so no sdk doc changes.


-d


On December 17, 2021 10:02:45 Dominik Psenner  wrote:


Hi Davyd,

I checked the changes since 2.0.13 and it looks good to me. Have you also
updated the log4net site? I would like to verify that the log4net website
looks good in staging.

Cheers
Dominik

On Thu, 16 Dec 2021 at 15:09, Davyd McColl 
wrote:


Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.

-d




--
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Robert

I checked and saw the same sha discrepencies - the only reason I can think of 
is perhaps I interrupted a release script such that I had updated artifacts but 
interrupted before the shas were computed. Fixed-up now, thanks for the 
heads-up. Just to be sure, I've updated the release artifacts at GitHub too.

-d

On 2021-12-17 08:28:35, Davyd McColl  wrote:
Hi Robert
Binaries are signed with my key, though I remember someone raising that my key 
wasn't in a known area last time, so I'd appreciate help with that. I had a key 
signing party with Ralph and Matt quite a long time ago, but perhaps there's 
something I was supposed to do that I didn't ):
The sha mismatch is more concerning because the production of artifacts is 
automated from a script in the repo, so I'll need to go double-check what's 
going on there. Thanks for the heads-up though.
-d

On December 17, 2021 02:17:24 Robert Middleton  wrote:
I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.


My understanding is that you don't upload to the release area until
the release is done.  Having the staging docs point at the release
area is fine to me at least(it's what I do for log4cxx), since that's
effectively a known issue with a release vote in my mind.
Anyway, I checked the binaries on
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], unfortunately it seems
as though there may be two problems:
1. SHA512 does not match the zip files at all
2. Signature doesn't seem to be valid, or I don't have the pubkey.
Which key is it signed with?
-Robert Middleton
On Thu, Dec 16, 2021 at 8:47 AM Davyd McColl  wrote:


Hi all
I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1]
I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.
Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.
-d
PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the
way. Please ignore the other if it pops up.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY 
[https://www.youtube.com/watch?v=-gXTZM_uPMY]
*Quidquid latine dictum sit, altum sonatur. *

Re: JIRA for tracking 1.x release? also some input.

[Leo Simons]

Hi Tony,

Glad you want to help. The original Log4J community left, so to get
anything done we need some new contributors!

On Thu, Dec 16, 2021 at 9:19 PM Homer, Tony  wrote:

> There has been some discussion about releasing a security update for log4j
> 1.x (1.2.18, perhaps), both here and on
> https://github.com/apache/logging-log4j2/pull/608.
> Is there a JIRA open for this work?
>

I don't think we really need an issue tracker, we can discuss the work here
on the mailing list and iterate on pull requests.

If we do need an issue tracker I would suggest enabling the github one
after making that a writable repo.
People have been making pull requests there for years...I guess since the
current github mirror repo doesn't clearly say log4j 1.x is
end-of-life...might as well go where the users are.
(I have no enthusiasm for using venerable bugzilla, I think it's even older
than log4j 1.2 ;-) )


> I'd like to provide some input, specifically that any security update
> should consider all of the following CVES:
>
> https://nvd.nist.gov/vuln/detail/CVE-2019-17571
> consider starting with the Debian patch
> discussion:
> https://lists.debian.org/debian-lts-announce/2020/01/msg8.html
> download: https://packages.debian.org/stretch/liblog4j1.2-java
> changelog:
> https://metadata.ftp-master.debian.org/changelogs//main/a/apache-log4j1.2/apache-log4j1.2_1.2.17-7+deb9u1_changelog
> <
> https://metadata.ftp-master.debian.org/changelogs/main/a/apache-log4j1.2/apache-log4j1.2_1.2.17-7+deb9u1_changelog
> >
>

Hmm, that Debian patch is very minimal/conservative. On the branch I'm
working on I disabled many socket things much more thoroughly:

https://github.com/apache/log4j/pull/16

Also reviewed the other patches they have in debian on liblog4j1.2, I think
none are worth upstreaming.


> https://nvd.nist.gov/vuln/detail/CVE-2020-9488
> consider removing SMTPAppender (brute force mitigation)
>

I've been thinking about this one today.

The vulnerability description here is kind of limited: "Improper validation
of certificate with host mismatch".
Put another way: very little attempt is made when using SMTPS to do a good
job at SSL.
On the other hand there is also no assertion anywhere the approach used is
particularly secure.
At a guess, when the code was written, it was a reasonable assumption the
JDK should do secure-by-default certificate verification/pinning/etc.
Actually, you could still argue that :)
The CVE has a base score of 3.7 (LOW), unlike other appenders at least it
has some support for encryption...through what the JDK builds in for SMTPS.

By the way, that's only one of the issues with this SMTPAppender,
apparently another one is that it can generate huge amounts of email:

https://github.com/apache/log4j/pull/6

but such a PR also shows that the appender has at least some users.
There's probably also users who configure it with insecure SMTP, who you
could say have reasonable expectations that it's an insecure connection.
(Maybe they talk SMTP to localhost?)

So I don't know about disabling it completely. I'm more inclined to log a
stern warning, like I'm doing for syslog:


https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/helpers/SyslogWriter.java#L95

What do you think?

Of course the right fix if you want to log to SMTP is to upgrade to 2.x,
which has a nice new builder API that allows passing SSL configuration.
Backporting that seems like way too much work.


> https://nvd.nist.gov/vuln/detail/CVE-2021-4104
> consider removing JMSAppender (brute force mitigation)
>

Note removing the classes would break API compatibility. Instead I'm
opting to remove the functionality while keeping the API signature:


https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/net/JMSAppender.java

Fixes the security issue while allowing for a drop-in replacement jar.

Cheers,

Leo

Re: JIRA for tracking 1.x release? also some input.

[Vladimir Sitnikov]

>If we do need an issue tracker I would suggest enabling the github one
>after making that a writable repo

+1. If we need a tracker, then GitHub issues is the way to go.

>Note removing the classes would break API compatibility

I do not think keeping the class with "every method throws" is much better
than just removing the class.
However, the CVE in JMSAppender is like "if the attacker can modify logging
configuration".
Well, in case the attacker can modify configuration files, then you have
much worse issues than "reconfiguring log4j".

One of the ways to harden that is to limit "acceptable" names to
"alphanumeric" or "alphanumeric + slash".
I believe lookup for alphanumeric still allows certain cases to work, yet
it blocks ldap:// indirections.

However, I am not sure if JMSAppender is really used often (nowadays
KafkaAppender would get much more love :) ).
It might make sense to ship log4j1-nonetwork.jar along with regular
log4j.jar

Vladimir

Log4J 1.x progress, pull request(s), plans

[Leo Simons]

Hey,

Progress today

As mentioned I made a draft PR for the branch I'm working on:

https://github.com/apache/log4j/pull/16

My main progress today was to get the unit test suite working reliably
(dozens of tests were disabled because they had flaky results), and then to
get build and test to run reliably on a bunch of different JDK/toolchain/OS
combos, using github actions for CI:

https://github.com/lsimons/log4j/actions/runs/1593087224

I also read through the SyslogAppender which I thought about
disabling completely, but have opted for a stern warning instead for any
configs that write to non-localhost.

In the net package, SMTPAppender still needs more of an opinion on what to
do exactly (see some notes on the e-mail thread Tony started).

Other PRs

I've also cherry-picked a couple of reasonable PRs into the branch I'm
working on:

https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
https://github.com/apache/log4j/pull/10 (by Vincent Privat)

For the remaining ones I went through them and wrote suggestions for what I
think should happen, which amounts to: all PRs except for the new #16
should be closed. (I don't have permission to click "Close" of course.)

Integration tests

Existing test suite took so much time that I didn't get around to starting
on any integration tests yet.

I would like to have some fixture projects set up into which to auto-inject
different problematic config files and 1.x libraries, assert there is a
problem, replace with the new library, assert it's ok.

Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
scripts / docker / ...), so you don't need to know java to see the problem
or to verify the solution.

...and then it'd make sense to me to have another git repo.


Cheers,


Leo

Re: JIRA for tracking 1.x release? also some input.

[Leo Simons]

On Fri, Dec 17, 2021 at 6:24 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >Note removing the classes would break API compatibility
>
> I do not think keeping the class with "every method throws" is much better
> than just removing the class.
>

Agreed! I also don't want to do "every method throws". That indeed wouldn't
help. I want

* doesn't ever listen on any ports
* doesn't ever do unsafe deserialization (or otherwise unsafely consumes
data)
* otherwise behaves as can be expected given its existing configuration
* use of a problem library class means an error message on startup, but
still startup and perhaps working (other) logging
* use of a problem   main()   entrypoint logs an error and exits
* drop in binary replacement jar with full binary compatibility: if it
starts up now it will still start up

The reason to keep the classes and their public+protected API is to support
people who have used the library as a library.

Imagine some software that has something like:

  public class CustomJMSAppender extends JMSAppender {
// XXX try and hardcode JMS, am not allowed JMX console access, YOLO
private final static String MY_PROVIDER_URL = "jms:something:something";

public CustomJMSAppender() {
  this.setProviderURL(MY_PROVIDER_URL);
}

public void setProviderURL(String providerURL) {
  super.setProviderURL(MY_PROVIDER_URL);
}
  }

log4j being a flexible library full of extension points with public
non-final classes and many many users makes it almost a certainty someone
is stuck maintaining a system like this.
Without the source code.
On Java 1.4.

If we delete JMSAppender, and then that poor admin replaces
log4j-1.2.17.jar with log4j-1.2.18.jar, good chance their software won't
start.

Does that make sense?


Cheers,


Leo

RE: JIRA for tracking 1.x release? also some input.

[Homer, Tony]

I'm glad to see the activity (!), but I'm having a hard time keeping up with 
the responses to this thread, sorry if I am out of order.

>> (Leo) Glad you want to help. The original Log4J community left, so to get 
>> anything done we need some new contributors!

I'm fine with skipping the issue tracker, but FWIW I was thinking of using the 
Log4j 2 JIRA project, not Log4j Bugzilla.
https://issues.apache.org/jira/projects/LOG4J2/issues
I'm not a fan of enabling GitHub Issues and am not suggesting that.
I think we should consider whether the objective is to resurrect Log4j 1.x or 
just provide a one-time patch along with making it possible to create future 
one-time patches.
Enabling GitHub issues makes it seem like the project is being resurrected, 
which I do not think it anyone's intention.

>> (Leo) comments on the following CVEs
> https://nvd.nist.gov/vuln/detail/CVE-2020-9488
> https://nvd.nist.gov/vuln/detail/CVE-2021-4104
The reason I suggested the brute force approach is because I don't think we 
want to encourage people to keep using 1.x.
The brute force approach will be effective with minimal review required.
I agree that a great alternative to removal is an empty implementation that 
preserves the existing interface.

>> (Leo) Hmm, that Debian patch is very minimal/conservative
WRT CVE-2019-17571, it sounds like you are ahead of the Debian patch, great!
That being said, if we aren't trying to resurrect Log4j 1.x for active 
maintenance, we should favor a simple approach.

I'll take a look at your PRs ASAP, but fighting a lot of other Log4Shell fires, 
so it might take a while.

-Original Message-
From: Vladimir Sitnikov  
Sent: Friday, December 17, 2021 9:24 AM
To: dev@logging.apache.org
Subject: Re: JIRA for tracking 1.x release? also some input.

>If we do need an issue tracker I would suggest enabling the github one 
>after making that a writable repo

+1. If we need a tracker, then GitHub issues is the way to go.

>Note removing the classes would break API compatibility

I do not think keeping the class with "every method throws" is much better than 
just removing the class.
However, the CVE in JMSAppender is like "if the attacker can modify logging 
configuration".
Well, in case the attacker can modify configuration files, then you have much 
worse issues than "reconfiguring log4j".

One of the ways to harden that is to limit "acceptable" names to "alphanumeric" 
or "alphanumeric + slash".
I believe lookup for alphanumeric still allows certain cases to work, yet it 
blocks ldap:// indirections.

However, I am not sure if JMSAppender is really used often (nowadays 
KafkaAppender would get much more love :) ).
It might make sense to ship log4j1-nonetwork.jar along with regular log4j.jar

Vladimir

Re: Log4J 1.x progress, pull request(s), plans

[Ralph Goers]

I am still questioning the plan. If you are planning on just creating a 
security release 
and then having the project go back to its coffin then I am not sure why all 
the tooling
 is needed.  OTOH, if you want to resurrect the project then this really should 
go through 
the ASF incubator with the Logging Services project as the sponsor.

Ralph

> On Dec 17, 2021, at 10:24 AM, Leo Simons  wrote:
> 
> Hey,
> 
> Progress today
> 
> As mentioned I made a draft PR for the branch I'm working on:
> 
>https://github.com/apache/log4j/pull/16
> 
> My main progress today was to get the unit test suite working reliably
> (dozens of tests were disabled because they had flaky results), and then to
> get build and test to run reliably on a bunch of different JDK/toolchain/OS
> combos, using github actions for CI:
> 
>https://github.com/lsimons/log4j/actions/runs/1593087224
> 
> I also read through the SyslogAppender which I thought about
> disabling completely, but have opted for a stern warning instead for any
> configs that write to non-localhost.
> 
> In the net package, SMTPAppender still needs more of an opinion on what to
> do exactly (see some notes on the e-mail thread Tony started).
> 
> Other PRs
> 
> I've also cherry-picked a couple of reasonable PRs into the branch I'm
> working on:
> 
>https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
>https://github.com/apache/log4j/pull/10 (by Vincent Privat)
> 
> For the remaining ones I went through them and wrote suggestions for what I
> think should happen, which amounts to: all PRs except for the new #16
> should be closed. (I don't have permission to click "Close" of course.)
> 
> Integration tests
> 
> Existing test suite took so much time that I didn't get around to starting
> on any integration tests yet.
> 
> I would like to have some fixture projects set up into which to auto-inject
> different problematic config files and 1.x libraries, assert there is a
> problem, replace with the new library, assert it's ok.
> 
> Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
> scripts / docker / ...), so you don't need to know java to see the problem
> or to verify the solution.
> 
> ...and then it'd make sense to me to have another git repo.
> 
> 
> Cheers,
> 
> 
> Leo

Re: Log4J 1.x progress, pull request(s), plans

[Matt Sicker]

It's possible that it's not buildable without updates to the build
scripts. If that's the case, then they should be updated.

On Fri, Dec 17, 2021 at 12:28 PM Ralph Goers  wrote:
>
> I am still questioning the plan. If you are planning on just creating a 
> security release
> and then having the project go back to its coffin then I am not sure why all 
> the tooling
>  is needed.  OTOH, if you want to resurrect the project then this really 
> should go through
> the ASF incubator with the Logging Services project as the sponsor.
>
> Ralph
>
> > On Dec 17, 2021, at 10:24 AM, Leo Simons  wrote:
> >
> > Hey,
> >
> > Progress today
> > 
> > As mentioned I made a draft PR for the branch I'm working on:
> >
> >https://github.com/apache/log4j/pull/16
> >
> > My main progress today was to get the unit test suite working reliably
> > (dozens of tests were disabled because they had flaky results), and then to
> > get build and test to run reliably on a bunch of different JDK/toolchain/OS
> > combos, using github actions for CI:
> >
> >https://github.com/lsimons/log4j/actions/runs/1593087224
> >
> > I also read through the SyslogAppender which I thought about
> > disabling completely, but have opted for a stern warning instead for any
> > configs that write to non-localhost.
> >
> > In the net package, SMTPAppender still needs more of an opinion on what to
> > do exactly (see some notes on the e-mail thread Tony started).
> >
> > Other PRs
> > 
> > I've also cherry-picked a couple of reasonable PRs into the branch I'm
> > working on:
> >
> >https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga)
> >https://github.com/apache/log4j/pull/10 (by Vincent Privat)
> >
> > For the remaining ones I went through them and wrote suggestions for what I
> > think should happen, which amounts to: all PRs except for the new #16
> > should be closed. (I don't have permission to click "Close" of course.)
> >
> > Integration tests
> > 
> > Existing test suite took so much time that I didn't get around to starting
> > on any integration tests yet.
> >
> > I would like to have some fixture projects set up into which to auto-inject
> > different problematic config files and 1.x libraries, assert there is a
> > problem, replace with the new library, assert it's ok.
> >
> > Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell
> > scripts / docker / ...), so you don't need to know java to see the problem
> > or to verify the solution.
> >
> > ...and then it'd make sense to me to have another git repo.
> >
> >
> > Cheers,
> >
> >
> > Leo
>

[Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

[Milind Wankhede]

Good Morning/Afternoon,
As you may know, a cyber-vulnerability impacting Java Library: log4j was 
recently identified.
DHS warns of critical flaw in widely used software - 
CNNPolitics

As a result and to provide our regulators confidence in our management of the 
impact, we are engaging our vendors to determine both if they were impacted 
(Yes/No) and if "Yes" what "Actions were taken?"

We ask you consider in your response any 3rd party vendors which your business 
may share SMBC data with as well.

We are looking for impact on Log4Net project/Library.

Vendor Reported Impact (Yes or No)
Actions Taken (If Any or N/A)
Impact to SMBC (Yes/No)


Please reply to all on this mail.

To ensure we are in compliance with regulatory obligations we ask that you 
please respond within 48 hours of this mail.

Thank you,


Thanks & Regards!
Milind Wankhede
SMBC Capital Markets, Inc.
277 Park Ave New York NY 10172
Phone: (212) 224-5221 | Email:  
mwankh...@smbc-cm.com

This message, including any attachments, may contain information that is 
privileged, confidential and/or protected by copyright, and is subject to the 
terms available at  
https://www.smbcgroup.com/americas/disclaimers/emaildisclaimer.html/ 
If you are not the intended recipient, or have received this message in error, 
please notify the sender immediately and delete this message.

Re: [Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

[Dominik Psenner]

Hi Milind,

log4net is not log4j and therefore the recent log4j vulnerability is
unrelated to log4net. Beyond that, the Apache Software Foundation is vendor
neutral.

Warm regards,
Dominik

On Fri, 17 Dec 2021 at 22:24, Milind Wankhede  wrote:

> Good Morning/Afternoon,
> As you may know, a cyber-vulnerability impacting Java Library: log4j was
> recently identified.
> DHS warns of critical flaw in widely used software - CNNPolitics<
> https://www.cnn.com/2021/12/11/politics/dhs-log4j-software-flaw-warning/index.html
> >
>
> As a result and to provide our regulators confidence in our management of
> the impact, we are engaging our vendors to determine both if they were
> impacted (Yes/No) and if "Yes" what "Actions were taken?"
>
> We ask you consider in your response any 3rd party vendors which your
> business may share SMBC data with as well.
>
> We are looking for impact on Log4Net project/Library.
>
> Vendor Reported Impact (Yes or No)
> Actions Taken (If Any or N/A)
> Impact to SMBC (Yes/No)
>
>
> Please reply to all on this mail.
>
> To ensure we are in compliance with regulatory obligations we ask that you
> please respond within 48 hours of this mail.
>
> Thank you,
>
>
> Thanks & Regards!
> Milind Wankhede
> SMBC Capital Markets, Inc.
> 277 Park Ave New York NY 10172
> Phone: (212) 224-5221 | Email:  mwankh...@smbc-cm.com mwankh...@smbc-cm.com>
>
> This message, including any attachments, may contain information that is
> privileged, confidential and/or protected by copyright, and is subject to
> the terms available at
> https://www.smbcgroup.com/americas/disclaimers/emaildisclaimer.html/
> If you are not the intended recipient, or have received this message in
> error, please notify the sender immediately and delete this message.
>


-- 
Dominik Psenner

[VOTE] Release Apache Log4j 2.17.0-rc1

[Ralph Goers]

This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 project.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the 
release. All votes are welcome and we encourage everyone to test the release, 
but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
votes and more positive than negative votes are required.

Note that a pre-release version of this was distributed to all reporters of the 
issue covered by CVE-2021-45105 and all who tested confirmed the issue was 
addressed.

Changes in this version include:

Fixed Bugs

• LOG4J2-3230: Fix string substitution recursion.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. The enablement property has been renamed to 
'log4j2.enableJndiJava'
• LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
dependencies as it causes problems with the Maven enforcer plugin.
• LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
parsing properties file filters.
• LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
512 instead of 514.
• LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
TCP.

Tag: 
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
and then "git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b 
log4j-2.17.0-rc1 https://github.com/apache/logging-log4j2.git";
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.17.0-rc1”

Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1071

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/

Ralph

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Carter Kozak]

+1

build + rat are good

-ck

On Fri, Dec 17, 2021, at 22:18, Ralph Goers wrote:
> This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 
> project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. All votes are welcome and we encourage everyone to test the release, 
> but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
> votes and more positive than negative votes are required.
> 
> Note that a pre-release version of this was distributed to all reporters of 
> the issue covered by CVE-2021-45105 and all who tested confirmed the issue 
> was addressed.
> 
> Changes in this version include:
> 
> Fixed Bugs
> 
> • LOG4J2-3230: Fix string substitution recursion.
> • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
> to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
> 'log4j2.enableJndiContextSelector'.
> • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. The enablement property has been renamed to 
> 'log4j2.enableJndiJava'
> • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
> dependencies as it causes problems with the Maven enforcer plugin.
> • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when parsing 
> properties file filters.
> • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 512 
> instead of 514.
> • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to TCP.
> 
> Tag: 
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> and then "git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b 
> log4j-2.17.0-rc1 https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.17.0-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1071
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
> 
> Ralph

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Gary Gregory]

+1

Building from the git tag (tags/log4j-2.17.0-rc1 a19ef9bce) OK; running:

- mvn clean install
- mvn site -DskipTests
- mvn apache-rat:check -DskipTests

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_312, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.1", arch: "x86_64", family: "mac"

Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54
PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

Gary


On Fri, Dec 17, 2021 at 10:18 PM Ralph Goers  wrote:
>
> This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The vote will remain open for as short amount as time as required to vet the 
> release. All votes are welcome and we encourage everyone to test the release, 
> but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
> votes and more positive than negative votes are required.
>
> Note that a pre-release version of this was distributed to all reporters of 
> the issue covered by CVE-2021-45105 and all who tested confirmed the issue 
> was addressed.
>
> Changes in this version include:
>
> Fixed Bugs
>
> • LOG4J2-3230: Fix string substitution recursion.
> • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
> to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
> 'log4j2.enableJndiContextSelector'.
> • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. The enablement property has been renamed to 
> 'log4j2.enableJndiJava'
> • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
> dependencies as it causes problems with the Maven enforcer plugin.
> • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
> parsing properties file filters.
> • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
> 512 instead of 514.
> • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
> TCP.
>
> Tag:
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> and then "git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b 
> log4j-2.17.0-rc1 https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.17.0-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1071
>
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
>
> Ralph

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Matt Sicker]

+1

Checked build, tests, sigs, site, etc.
--
Matt Sicker

> On Dec 17, 2021, at 21:18, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 
> project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. All votes are welcome and we encourage everyone to test the release, 
> but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
> votes and more positive than negative votes are required.
> 
> Note that a pre-release version of this was distributed to all reporters of 
> the issue covered by CVE-2021-45105 and all who tested confirmed the issue 
> was addressed.
> 
> Changes in this version include:
> 
> Fixed Bugs
> 
>   • LOG4J2-3230: Fix string substitution recursion.
>   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
> to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
> 'log4j2.enableJndiContextSelector'.
>   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. The enablement property has been renamed to 
> 'log4j2.enableJndiJava'
>   • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
> dependencies as it causes problems with the Maven enforcer plugin.
>   • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
> parsing properties file filters.
>   • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
> 512 instead of 514.
>   • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
> TCP.
> 
> Tag: 
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> and then "git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b 
> log4j-2.17.0-rc1 https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.17.0-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1071
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
> 
> Ralph

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Ron Grabowski]

+1

mvn clean install
mvn apache-rat:check

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: C:\projects\apache-maven-3.8.4
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.8.0_181\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On 12/17/2021 10:18 PM, Ralph Goers wrote:

This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 project.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for as short amount as time as required to vet the 
release. All votes are welcome and we encourage everyone to test the release, 
but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
votes and more positive than negative votes are required.

Note that a pre-release version of this was distributed to all reporters of the 
issue covered by CVE-2021-45105 and all who tested confirmed the issue was 
addressed.

Changes in this version include:

Fixed Bugs

• LOG4J2-3230: Fix string substitution recursion.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. The enablement property has been renamed to 
'log4j2.enableJndiJava'
• LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
dependencies as it causes problems with the Maven enforcer plugin.
• LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
parsing properties file filters.
• LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
512 instead of 514.
• LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
TCP.

Tag:
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git and then 
"git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b log4j-2.17.0-rc1 
https://github.com/apache/logging-log4j2.git";
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.17.0-rc1”

Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1071

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/

Ralph

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Remko Popma]

+1

GNU signatures check ok.

Build passed with
maven clean install

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

About the signatures:
I only see asc file, md5 and sha1 files; I was able to verify the GPG sigs
(asc), but not the md5 or sha1 files:

find . -type f -name *.sha1 -exec sha1sum -c {} \;
find . -type f -name *.md5 -exec md5sum -c {} \;
Both these commands give errors like "no properly formatted SHA1 checksum
lines found"... so not good.
But as per Apache guidelines we should not use md5 or sha1, so ignoring
that for now.

I cannot find any sha512 signatures anywhere though...




On Sat, Dec 18, 2021 at 1:16 PM Ron Grabowski
 wrote:

> +1
>
> mvn clean install
> mvn apache-rat:check
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: C:\projects\apache-maven-3.8.4
> Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_181\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> On 12/17/2021 10:18 PM, Ralph Goers wrote:
> > This is a vote to release Log4j 2.17.0, the next version of the Log4j 2
> project.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Note that a pre-release version of this was distributed to all reporters
> of the issue covered by CVE-2021-45105 and all who tested confirmed the
> issue was addressed.
> >
> > Changes in this version include:
> >
> > Fixed Bugs
> >
> >   • LOG4J2-3230: Fix string substitution recursion.
> >   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will
> remain disabled by default. Rename JNDI enablement property from
> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms',
> and 'log4j2.enableJndiContextSelector'.
> >   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will
> remain disabled by default. The enablement property has been renamed to
> 'log4j2.enableJndiJava'
> >   • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9
> as dependencies as it causes problems with the Maven enforcer plugin.
> >   • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE
> when parsing properties file filters.
> >   • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to
> port 512 instead of 514.
> >   • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol
> to TCP.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git and then "git checkout
> tags/log4j-2.17.0-rc1”  or just "git clone -b log4j-2.17.0-rc1
> https://github.com/apache/logging-log4j2.git";
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.17.0-rc1”
> >
> > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1071
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
> >
> > Ralph
>

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Ralph Goers]

My +1

Ralph

> On Dec 17, 2021, at 8:18 PM, Ralph Goers  wrote:
> 
> This is a vote to release Log4j 2.17.0, the next version of the Log4j 2 
> project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for as short amount as time as required to vet the 
> release. All votes are welcome and we encourage everyone to test the release, 
> but only Logging PMC votes are “officially” counted. As always, at least 3 +1 
> votes and more positive than negative votes are required.
> 
> Note that a pre-release version of this was distributed to all reporters of 
> the issue covered by CVE-2021-45105 and all who tested confirmed the issue 
> was addressed.
> 
> Changes in this version include:
> 
> Fixed Bugs
> 
>   • LOG4J2-3230: Fix string substitution recursion.
>   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
> to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
> 'log4j2.enableJndiContextSelector'.
>   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
> disabled by default. The enablement property has been renamed to 
> 'log4j2.enableJndiJava'
>   • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
> dependencies as it causes problems with the Maven enforcer plugin.
>   • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
> parsing properties file filters.
>   • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
> 512 instead of 514.
>   • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
> TCP.
> 
> Tag: 
> a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
> and then "git checkout tags/log4j-2.17.0-rc1”  or just "git clone -b 
> log4j-2.17.0-rc1 https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.17.0-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1071
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
> 
> Ralph

[RESULT][VOTE] Release Apache Log4j 2.17.0-rc1

[Ralph Goers]

This vote received +1 from Carter Kozak, Gary Gregory, Matt Sicker, Ron 
Grabowski, Remko Popma, and Ralph Goers

Thank you all!

I will continue on with the release.

Ralph

Re: [Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

[Remko Popma]

Hi Milind,

Please take a look at this page, which has all the details:
https://logging.apache.org/log4j/2.x/security.html

In short, the log4net library is not impacted.
Only log4j (the java library) is impacted by this vulnerability.

Kind regards,
Remko


On Sat, Dec 18, 2021 at 6:24 AM Milind Wankhede 
wrote:

> Good Morning/Afternoon,
> As you may know, a cyber-vulnerability impacting Java Library: log4j was
> recently identified.
> DHS warns of critical flaw in widely used software - CNNPolitics<
> https://www.cnn.com/2021/12/11/politics/dhs-log4j-software-flaw-warning/index.html
> >
>
> As a result and to provide our regulators confidence in our management of
> the impact, we are engaging our vendors to determine both if they were
> impacted (Yes/No) and if "Yes" what "Actions were taken?"
>
> We ask you consider in your response any 3rd party vendors which your
> business may share SMBC data with as well.
>
> We are looking for impact on Log4Net project/Library.
>
> Vendor Reported Impact (Yes or No)
> Actions Taken (If Any or N/A)
> Impact to SMBC (Yes/No)
>
>
> Please reply to all on this mail.
>
> To ensure we are in compliance with regulatory obligations we ask that you
> please respond within 48 hours of this mail.
>
> Thank you,
>
>
> Thanks & Regards!
> Milind Wankhede
> SMBC Capital Markets, Inc.
> 277 Park Ave New York NY 10172
> Phone: (212) 224-5221 | Email:  mwankh...@smbc-cm.com mwankh...@smbc-cm.com>
>
> This message, including any attachments, may contain information that is
> privileged, confidential and/or protected by copyright, and is subject to
> the terms available at
> https://www.smbcgroup.com/americas/disclaimers/emaildisclaimer.html/
> If you are not the intended recipient, or have received this message in
> error, please notify the sender immediately and delete this message.
>