Re: [GitHub] [logging-log4j2] carterkozak commented on a change in pull request #657: Api separation documentation

[Matt Sicker]

The $h2 things are to get around Velocity syntax and Markdown syntax for 
headers getting confused. Same with the $dollar variable.
--
Matt Sicker

> On Dec 24, 2021, at 15:57, Robert Middleton  wrote:
> 
> There are some .md.vm files in that same directory, but I'm not sure
> exactly how that works - it looks like it will do variable
> replacement, but there are also some $h2 thingies there, so I didn't
> want to mess with figuring out how it all goes together.
> 
> -Robert Middleton
> 
> On Fri, Dec 24, 2021 at 4:37 PM Gary Gregory  wrote:
>> 
>> I versions need to be variables somehow, it's going to be forgotten for
>> each new release...
>> 
>> Gary
>> 
>> On Fri, Dec 24, 2021 at 4:27 PM GitBox  wrote:
>> 
>>> 
>>> carterkozak commented on a change in pull request #657:
>>> URL:
>>> https://github.com/apache/logging-log4j2/pull/657#discussion_r775080805
>>> 
>>> 
>>> 
>>> ##
>>> File path: src/site/markdown/api-separation.md
>>> ##
>>> @@ -0,0 +1,241 @@
>>> +
>>> +
>>> +
>>> +# API Separation
>>> +
>>> +When selecting a logging library, some care must be taken in order to
>>> ensure
>>> +that multiple different logging libraries are properly accounted for.  For
>>> +example, library code that you depend on may use slf4j, while other
>>> libraries
>>> +may simply use java.util.logging.  All of these can be routed to the log4j
>>> +core in order to be logged.
>>> +
>>> +If however you want to use a different logging implementation(such as
>>> logback),
>>> +it is possible to route messages from the Log4j API to logback, ensuring
>>> that
>>> +your application is not tied to a specific logging framework.
>>> +
>>> +A typical class using the Log4j2 API looks like the following:
>>> +
>>> +```java
>>> +import org.apache.logging.log4j.LogManager;
>>> +import org.apache.logging.log4j.Logger;
>>> +
>>> +public class Log4j2Test {
>>> +private static final Logger logger = LogManager.getLogger();
>>> +
>>> +public Log4j2Test(){
>>> +logger.info( "Hello World!" );
>>> +}
>>> +}
>>> +```
>>> +
>>> +In order to use the API portion of Log4j2, we only need to provide a
>>> single
>>> +dependency, log4j-api.  Using Maven, you would add the following to your
>>> +dependencies:
>>> +
>>> +```
>>> +
>>> +org.apache.logging.log4j
>>> +log4j-api
>>> +2.17.0
>>> +
>>> +```
>>> +
>>> +## Using Log4j2 API and Core
>>> +
>>> +Using the Log4j2 API and Core together means that log messages will be
>>> routed
>>> +through the Log4j2 Core.  The Log4j2 core is responsible for the
>>> +following(note: this is not an exhaustive list):
>>> +
>>> +* Configuration of the system(via an XML file for example)
>>> +* Routing messages to appenders
>>> +* Opening files and other resources for logs(e.g. network sockets)
>>> +
>>> +When using the Log4j2 core, this means that your config file must match
>>> the
>>> +[configuration](manual/configuration.html) used by Log4j2.
>>> +
>>> +To use both the API and the core, you would add the following to your
>>> +dependencies(assuming that you are using Maven):
>>> +
>>> +```
>>> +
>>> +org.apache.logging.log4j
>>> +log4j-api
>>> +2.17.0
>>> +
>>> +
>>> +org.apache.logging.log4j
>>> +log4j-core
>>> +2.17.0
>>> +
>>> +```
>>> +
>>> +Note that having two different versions of log4j-api and log4j-core on
>>> your
>>> +classpath is not guaranteed to work correctly(e.g. 2.15 of log4j-api and
>>> +2.17 of log4j-core).
>>> +
>>> +##  Using Log4j2 API with Logback
>>> +
>>> +Since the Log4j2 API is generic, we can use it to send messages via SLF4J
>>> +and then have Logback do the actual logging of the messages.  This means
>>> +that you can write your code tied to the Log4j2 API, but users of your
>>> +code do not need to use the Log4j2 core if they are already using Logback.
>>> +
>>> +To switch to using Logback, you will need to add the following to your
>>> +dependencies(assumging that you are using Maven):
>>> +
>>> +```
>>> +
>>> +org.apache.logging.log4j
>>> +log4j-api
>>> +2.17.0
>>> +
>>> +
>>> +org.apache.logging.log4j
>>> +log4j-to-slf4j
>>> +2.17.0
>>> +
>>> +
>>> +  ch.qos.logback
>>> +  logback-classic
>>> +  1.2.10
>>> +
>>> +```
>>> +
>>> +## Using Log4j2 as an SLF4J Implementation
>>> +
>>> +If you don't want to depend on the Log4j2 API and instead want to use
>>> SLF4J,
>>> +that is possible as well.  Assuming that our code looks like the
>>> following:
>>> +
>>> +```java
>>> +import org.slf4j.Logger;
>>> +import org.slf4j.LoggerFactory;
>>> +
>>> +public class Log4j2Test {
>>> +
>>> +private static final Logger logger =
>>> LoggerFactory.getLogger(Log4j2Test.class);
>>> +
>>> +public Log4j2Test(){
>>> +logger.info( "Hello World!" );
>>> +}
>>> +}
>>> +```
>>> +
>>> +We can then route the messages to Log4j2 using the log4j-slf4j-impl like
>>> the following:
>>> +
>>> +```
>>> +
>>> +org.slf4j
>>> +slf4j-api
>>> +1.7.32
>>> +
>>> +
>>> +  

Re: Mapping CVEs to Log4j and Java versions.

[Gary Gregory]

On Fri, Dec 24, 2021 at 5:35 PM Ralph Goers 
wrote:

> The stuff on the about page is “news” and will disappear in an upcoming
> release. The security page will stick around indefinitely.
>

Ah, I did not get that. Now I do.

Gary


>
> Ralph
>
> > On Dec 24, 2021, at 3:20 PM, Gary Gregory 
> wrote:
> >
> > Hi All:
> >
> > I find it hard to track what CVE is associated with what Log4j version
> and
> > Java version, so I created this table:
> >
> https://github.com/apache/logging-log4j2/blob/release-2.x/docs/cve-map.md
> >
> > In general, I'm not a fan of duplicating information like we do on our
> > About page and Security page, I worry that I am missing something unless
> I
> > read _everything_ and it's harder to maintain too.
> >
> > Gary
>
>

Re: Mapping CVEs to Log4j and Java versions.

[Ralph Goers]

The stuff on the about page is “news” and will disappear in an upcoming 
release. The security page will stick around indefinitely.

Ralph

> On Dec 24, 2021, at 3:20 PM, Gary Gregory  wrote:
> 
> Hi All:
> 
> I find it hard to track what CVE is associated with what Log4j version and
> Java version, so I created this table:
> https://github.com/apache/logging-log4j2/blob/release-2.x/docs/cve-map.md
> 
> In general, I'm not a fan of duplicating information like we do on our
> About page and Security page, I worry that I am missing something unless I
> read _everything_ and it's harder to maintain too.
> 
> Gary

Re: [DISCUSS] The future of Log4j 1.x

[Gary Gregory]

On Fri, Dec 24, 2021 at 5:21 PM Dominik Psenner  wrote:

> I am in favor of option 1, basically this:
>
> * Add an EOL marker, big and bold
> * Allow the repository to be cloned
> * Allow the repository to be forked
> * Disable the creation of new pull requests (on github)
> * Disable creation of issues (on github; this is the default; I want to
> stress this by mentioning it explicitly)
>
> My reasoning behind this is that an EOL must not consume resources. Any
> resource available should be invested in something that is not EOL so that
> opportunities are not lost with friction or distraction.
>
> Having this, someone can easily fork/clone the repository on github and
> work on the codebase. We may consider accepting these patches as
> contributions in the future. So long logging services considers log4j1 EOL,
> people should be strongly encouraged to migrate and not to base their work
> on an EOL component.
>
> Why not allow creation of pull requests or issues? This clearly draws a
> line. Logging services is not investing resources in an EOL component. This
> enforces that any new commits happen on a fork or clone. This has the
> effect that the public could not become confused. In the perception of the
> general public any changes are clearly unrelated to Apache logging
> services. The position of Apache logging services is clearly that the
> component is EOL.
>
> Should valuable contributions appear in the future we may reconsider what
> to do. We could then for instance review changes in a fork and cherry pick
> the contributions. This could hold for minimal changes that fix CVEs. If
> changes are too large to be cherry picked, my gut feeling tells me that too
> many resources are invested in an EOL component.
>

Nice write up Dominick & something I can get behind.

Gary


>
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Fri, Dec 24, 2021, 17:47 Ralph Goers 
> wrote:
>
> > As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> > was released on May 26, 2012. The last commit was to update the
> > web site 7 years ago. The changes.xml file shows there were commits up to
> > sometime in 2012, all of which were performed by Gary Gregory
> > and Christian Grobmeier who ironically both voted no to opening the repo
> > back up.
> >
> > The point of this history is to point out that the project essentially
> > died in 2012. We simply acknowledged it in 2015.
> >
> > So now we have voted to open the repo. The question then becomes what to
> > do next and going forward. I see several options:
> >
> > 1. Create a README.md that publishes the projects EOL status and do
> > nothing else.
> > 2. Create a README.md that says the project is EOL and no further big
> > fixes or enhancements will be made but 1.2.18 was a special
> > circumstance. Perform ONLY the following work for 1.2.18:
> > a.  Make the build work with a modern version of Maven.
> > b.  Fix the Java version bug.
> > c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> > d.  Fix CVE-2019-17571
> > The expectation is that the above would address the actual issues and
> > not just remove classes.
> > Do NOT perform a release of any kind.
> > 3. Option 2 but only perform a source release.
> > 4. Option 2 but perform a full release.
> > 5. Option 4 but allow development to continue, including bug fixes and
> > enhancements.
> >
> > I personally can see valid reasons to do any of the above.  I have my own
> > opinion on this but I will post that in a reply to this discussion
> kickoff.
> >
> > If you have other proposals feel free to state them.
> >
> > This discussion will be followed up by a vote thread if necessary.
> >
> > Ralph
> >
> >
> >
>

Re: [DISCUSS] The future of Log4j 1.x

[Dominik Psenner]

I am in favor of option 1, basically this:

* Add an EOL marker, big and bold
* Allow the repository to be cloned
* Allow the repository to be forked
* Disable the creation of new pull requests (on github)
* Disable creation of issues (on github; this is the default; I want to
stress this by mentioning it explicitly)

My reasoning behind this is that an EOL must not consume resources. Any
resource available should be invested in something that is not EOL so that
opportunities are not lost with friction or distraction.

Having this, someone can easily fork/clone the repository on github and
work on the codebase. We may consider accepting these patches as
contributions in the future. So long logging services considers log4j1 EOL,
people should be strongly encouraged to migrate and not to base their work
on an EOL component.

Why not allow creation of pull requests or issues? This clearly draws a
line. Logging services is not investing resources in an EOL component. This
enforces that any new commits happen on a fork or clone. This has the
effect that the public could not become confused. In the perception of the
general public any changes are clearly unrelated to Apache logging
services. The position of Apache logging services is clearly that the
component is EOL.

Should valuable contributions appear in the future we may reconsider what
to do. We could then for instance review changes in a fork and cherry pick
the contributions. This could hold for minimal changes that fix CVEs. If
changes are too large to be cherry picked, my gut feeling tells me that too
many resources are invested in an EOL component.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Dec 24, 2021, 17:47 Ralph Goers  wrote:

> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> was released on May 26, 2012. The last commit was to update the
> web site 7 years ago. The changes.xml file shows there were commits up to
> sometime in 2012, all of which were performed by Gary Gregory
> and Christian Grobmeier who ironically both voted no to opening the repo
> back up.
>
> The point of this history is to point out that the project essentially
> died in 2012. We simply acknowledged it in 2015.
>
> So now we have voted to open the repo. The question then becomes what to
> do next and going forward. I see several options:
>
> 1. Create a README.md that publishes the projects EOL status and do
> nothing else.
> 2. Create a README.md that says the project is EOL and no further big
> fixes or enhancements will be made but 1.2.18 was a special
> circumstance. Perform ONLY the following work for 1.2.18:
> a.  Make the build work with a modern version of Maven.
> b.  Fix the Java version bug.
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> d.  Fix CVE-2019-17571
> The expectation is that the above would address the actual issues and
> not just remove classes.
> Do NOT perform a release of any kind.
> 3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
> 5. Option 4 but allow development to continue, including bug fixes and
> enhancements.
>
> I personally can see valid reasons to do any of the above.  I have my own
> opinion on this but I will post that in a reply to this discussion kickoff.
>
> If you have other proposals feel free to state them.
>
> This discussion will be followed up by a vote thread if necessary.
>
> Ralph
>
>
>

Mapping CVEs to Log4j and Java versions.

[Gary Gregory]

Hi All:

I find it hard to track what CVE is associated with what Log4j version and
Java version, so I created this table:
https://github.com/apache/logging-log4j2/blob/release-2.x/docs/cve-map.md

In general, I'm not a fan of duplicating information like we do on our
About page and Security page, I worry that I am missing something unless I
read _everything_ and it's harder to maintain too.

Gary

Re: [GitHub] [logging-log4j2] carterkozak commented on a change in pull request #657: Api separation documentation

[Robert Middleton]

There are some .md.vm files in that same directory, but I'm not sure
exactly how that works - it looks like it will do variable
replacement, but there are also some $h2 thingies there, so I didn't
want to mess with figuring out how it all goes together.

-Robert Middleton

On Fri, Dec 24, 2021 at 4:37 PM Gary Gregory  wrote:
>
> I versions need to be variables somehow, it's going to be forgotten for
> each new release...
>
> Gary
>
> On Fri, Dec 24, 2021 at 4:27 PM GitBox  wrote:
>
> >
> > carterkozak commented on a change in pull request #657:
> > URL:
> > https://github.com/apache/logging-log4j2/pull/657#discussion_r775080805
> >
> >
> >
> > ##
> > File path: src/site/markdown/api-separation.md
> > ##
> > @@ -0,0 +1,241 @@
> > +
> > +
> > +
> > +# API Separation
> > +
> > +When selecting a logging library, some care must be taken in order to
> > ensure
> > +that multiple different logging libraries are properly accounted for.  For
> > +example, library code that you depend on may use slf4j, while other
> > libraries
> > +may simply use java.util.logging.  All of these can be routed to the log4j
> > +core in order to be logged.
> > +
> > +If however you want to use a different logging implementation(such as
> > logback),
> > +it is possible to route messages from the Log4j API to logback, ensuring
> > that
> > +your application is not tied to a specific logging framework.
> > +
> > +A typical class using the Log4j2 API looks like the following:
> > +
> > +```java
> > +import org.apache.logging.log4j.LogManager;
> > +import org.apache.logging.log4j.Logger;
> > +
> > +public class Log4j2Test {
> > +private static final Logger logger = LogManager.getLogger();
> > +
> > +public Log4j2Test(){
> > +logger.info( "Hello World!" );
> > +}
> > +}
> > +```
> > +
> > +In order to use the API portion of Log4j2, we only need to provide a
> > single
> > +dependency, log4j-api.  Using Maven, you would add the following to your
> > +dependencies:
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +```
> > +
> > +## Using Log4j2 API and Core
> > +
> > +Using the Log4j2 API and Core together means that log messages will be
> > routed
> > +through the Log4j2 Core.  The Log4j2 core is responsible for the
> > +following(note: this is not an exhaustive list):
> > +
> > +* Configuration of the system(via an XML file for example)
> > +* Routing messages to appenders
> > +* Opening files and other resources for logs(e.g. network sockets)
> > +
> > +When using the Log4j2 core, this means that your config file must match
> > the
> > +[configuration](manual/configuration.html) used by Log4j2.
> > +
> > +To use both the API and the core, you would add the following to your
> > +dependencies(assuming that you are using Maven):
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +
> > +org.apache.logging.log4j
> > +log4j-core
> > +2.17.0
> > +
> > +```
> > +
> > +Note that having two different versions of log4j-api and log4j-core on
> > your
> > +classpath is not guaranteed to work correctly(e.g. 2.15 of log4j-api and
> > +2.17 of log4j-core).
> > +
> > +##  Using Log4j2 API with Logback
> > +
> > +Since the Log4j2 API is generic, we can use it to send messages via SLF4J
> > +and then have Logback do the actual logging of the messages.  This means
> > +that you can write your code tied to the Log4j2 API, but users of your
> > +code do not need to use the Log4j2 core if they are already using Logback.
> > +
> > +To switch to using Logback, you will need to add the following to your
> > +dependencies(assumging that you are using Maven):
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +
> > +org.apache.logging.log4j
> > +log4j-to-slf4j
> > +2.17.0
> > +
> > +
> > +  ch.qos.logback
> > +  logback-classic
> > +  1.2.10
> > +
> > +```
> > +
> > +## Using Log4j2 as an SLF4J Implementation
> > +
> > +If you don't want to depend on the Log4j2 API and instead want to use
> > SLF4J,
> > +that is possible as well.  Assuming that our code looks like the
> > following:
> > +
> > +```java
> > +import org.slf4j.Logger;
> > +import org.slf4j.LoggerFactory;
> > +
> > +public class Log4j2Test {
> > +
> > +private static final Logger logger =
> > LoggerFactory.getLogger(Log4j2Test.class);
> > +
> > +public Log4j2Test(){
> > +logger.info( "Hello World!" );
> > +}
> > +}
> > +```
> > +
> > +We can then route the messages to Log4j2 using the log4j-slf4j-impl like
> > the following:
> > +
> > +```
> > +
> > +org.slf4j
> > +slf4j-api
> > +1.7.32
> > +
> > +
> > +  org.apache.logging.log4j
> > +  log4j-slf4j-impl
> > +  2.17.0
> > +
> > +
> > +org.apache.logging.log4j
> > +log4j-core
> > +2.17.0
> > +
> > +```
> > +
> > +Note that if we were using SLF4J 1.8 instead of 1.7, that requires us 

Re: [GitHub] [logging-log4j2] carterkozak commented on a change in pull request #657: Api separation documentation

[Gary Gregory]

I versions need to be variables somehow, it's going to be forgotten for
each new release...

Gary

On Fri, Dec 24, 2021 at 4:27 PM GitBox  wrote:

>
> carterkozak commented on a change in pull request #657:
> URL:
> https://github.com/apache/logging-log4j2/pull/657#discussion_r775080805
>
>
>
> ##
> File path: src/site/markdown/api-separation.md
> ##
> @@ -0,0 +1,241 @@
> +
> +
> +
> +# API Separation
> +
> +When selecting a logging library, some care must be taken in order to
> ensure
> +that multiple different logging libraries are properly accounted for.  For
> +example, library code that you depend on may use slf4j, while other
> libraries
> +may simply use java.util.logging.  All of these can be routed to the log4j
> +core in order to be logged.
> +
> +If however you want to use a different logging implementation(such as
> logback),
> +it is possible to route messages from the Log4j API to logback, ensuring
> that
> +your application is not tied to a specific logging framework.
> +
> +A typical class using the Log4j2 API looks like the following:
> +
> +```java
> +import org.apache.logging.log4j.LogManager;
> +import org.apache.logging.log4j.Logger;
> +
> +public class Log4j2Test {
> +private static final Logger logger = LogManager.getLogger();
> +
> +public Log4j2Test(){
> +logger.info( "Hello World!" );
> +}
> +}
> +```
> +
> +In order to use the API portion of Log4j2, we only need to provide a
> single
> +dependency, log4j-api.  Using Maven, you would add the following to your
> +dependencies:
> +
> +```
> +
> +org.apache.logging.log4j
> +log4j-api
> +2.17.0
> +
> +```
> +
> +## Using Log4j2 API and Core
> +
> +Using the Log4j2 API and Core together means that log messages will be
> routed
> +through the Log4j2 Core.  The Log4j2 core is responsible for the
> +following(note: this is not an exhaustive list):
> +
> +* Configuration of the system(via an XML file for example)
> +* Routing messages to appenders
> +* Opening files and other resources for logs(e.g. network sockets)
> +
> +When using the Log4j2 core, this means that your config file must match
> the
> +[configuration](manual/configuration.html) used by Log4j2.
> +
> +To use both the API and the core, you would add the following to your
> +dependencies(assuming that you are using Maven):
> +
> +```
> +
> +org.apache.logging.log4j
> +log4j-api
> +2.17.0
> +
> +
> +org.apache.logging.log4j
> +log4j-core
> +2.17.0
> +
> +```
> +
> +Note that having two different versions of log4j-api and log4j-core on
> your
> +classpath is not guaranteed to work correctly(e.g. 2.15 of log4j-api and
> +2.17 of log4j-core).
> +
> +##  Using Log4j2 API with Logback
> +
> +Since the Log4j2 API is generic, we can use it to send messages via SLF4J
> +and then have Logback do the actual logging of the messages.  This means
> +that you can write your code tied to the Log4j2 API, but users of your
> +code do not need to use the Log4j2 core if they are already using Logback.
> +
> +To switch to using Logback, you will need to add the following to your
> +dependencies(assumging that you are using Maven):
> +
> +```
> +
> +org.apache.logging.log4j
> +log4j-api
> +2.17.0
> +
> +
> +org.apache.logging.log4j
> +log4j-to-slf4j
> +2.17.0
> +
> +
> +  ch.qos.logback
> +  logback-classic
> +  1.2.10
> +
> +```
> +
> +## Using Log4j2 as an SLF4J Implementation
> +
> +If you don't want to depend on the Log4j2 API and instead want to use
> SLF4J,
> +that is possible as well.  Assuming that our code looks like the
> following:
> +
> +```java
> +import org.slf4j.Logger;
> +import org.slf4j.LoggerFactory;
> +
> +public class Log4j2Test {
> +
> +private static final Logger logger =
> LoggerFactory.getLogger(Log4j2Test.class);
> +
> +public Log4j2Test(){
> +logger.info( "Hello World!" );
> +}
> +}
> +```
> +
> +We can then route the messages to Log4j2 using the log4j-slf4j-impl like
> the following:
> +
> +```
> +
> +org.slf4j
> +slf4j-api
> +1.7.32
> +
> +
> +  org.apache.logging.log4j
> +  log4j-slf4j-impl
> +  2.17.0
> +
> +
> +org.apache.logging.log4j
> +log4j-core
> +2.17.0
> +
> +```
> +
> +Note that if we were using SLF4J 1.8 instead of 1.7, that requires us to
> use
> +log4j-slf4j18-impl instead of log4j-slf4j-impl.
> +
> +## Using Log4j2 with JUL
> +
> +It is also possible to route messages that are logged using
> java.util.logging
> +to Log4j2.  Assuming that the code looks like the following:
> +
> +```java
> +import java.util.logging.Logger;
> +
> +public class Log4j2Test {
> +
> +private static final Logger logger =
> Logger.getLogger(Log4j2Test.class.getName());
> +
> +public Log4j2Test(){
> +logger.info( "Hello World!" );
> +}
> +```
> +
> +We can then also route these messages to the Log4j2 core by adding in the
> JUL bridge,
> +and setting the java.util.logging.manager property in the 

Re: [VOTE] Release log4net 2.0.14

[Ralph Goers]

+1

I checked the signature and hashes and those look good.  

I unzipped the source and binaries. The appropriate license and notice files 
are present.

I did not perform tests as I don’t have the necessary tools installed.

Ralph


> On Dec 23, 2021, at 1:36 PM, Matt Sicker  wrote:
> 
> Root keys are in https://downloads.apache.org/logging/KEYS which is in
> the dist repository where you commit releases.
> 
> On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner  wrote:
>> 
>> * old-log4net.snk.gpg has been the old key to sign binaries.
>> * @Matt, where is the root logging KEYS file located?
>> 
>> The changes in the release look good to me. +1
>> 
>> On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:
>> 
>>> Thanks Matt
>>> 
>>> Since you've given a +1, I'll write up some sticky notes to address these
>>> points in the near future.
>>> 
>>> -d
>>> 
>>> 
>>> On December 19, 2021 23:51:45 Matt Sicker  wrote:
>>> 
 +1
 
 Notes on the release:
 * I’ve copied your release signing key to the root logging KEYS file for
 easier discoverability.
 * The copyright year in the NOTICE file is a few years out of date at
>>> this
 point. I’ve updated this in master, though you’ll want to update this
>>> again
 in a couple weeks when it’s outdated again.
 * Some included files in the base directory of the source zip are
>>> missing
 copyright headers or shouldn’t even be included in the tarball (e.g.,
>>> the
 appveyor config file probably isn’t necessary)
  - Not sure what old-log4net.snk.gpg is in there for, either.
  - Gulp task source files missing headers
 * Artifact signatures and sha512 hashes look good (checked with shasum
 which is the Perl script version), contain appropriate LICENSE and
>>> NOTICE
 (besides the outdated copyright year, but not a blocker), no binaries in
 the source zip, appropriate files in the binary zip.
 
 --
 Matt Sicker
 
> On Dec 16, 2021, at 07:47, 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
> 
> 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
> 
> *Quidquid latine dictum sit, altum sonatur. *
 
>>> 
>> 
>> 
>> --
>> Dominik Psenner
> 

Re: [DISCUSS] The future of Log4j 1.x

[Matt Sicker]

I’d be in favor of 1 or 4. Option 5 isn’t very feasible right now evidenced by 
how difficult it is to get enough votes on most of our other subproject 
releases like log4net, log4cxx, Log4j Scala API, and Log4j Kotlin API. There’s 
a long history in this PMC of wondering whether or not to continue developing 
various subprojects due to lack of community activity.
--
Matt Sicker

> On Dec 24, 2021, at 12:30, Ralph Goers  wrote:
> 
> If I were to vote today it would probably be for option 1. I had a discussion 
> with another ASF member yesterday who reminded me that in projects 
> like Tomcat EOL means EOL. Once that date is hit under no circumstances will 
> they issue a new release.
> 
> However, I understand that there is a difference between Log4j and Tomcat. 
> Tomcat 4 vs 5 would not have been a completely new and 
> incompatible architecture as Log4j 2 was. On the other hand I created the 
> compatibility bridge 2 years ago and it is quite clear that some of the 
> people looking to fix Log4j 1 have no idea it exists and/or have never tried 
> it. My preference would be to focus on fixing whatever issues are found 
> in that. 
> 
> Options 2 & 3 are interesting because they indicate that the project is still 
> EOL. But they don’t really help anyone much. So if any work is done on 
> the Log4j 1 code base I would generally agree that option 4 is the best 
> choice.
> 
> I am also -1 on option 5. If option 4 is chosen it is possible I could be 
> persuaded to do another CVE release should one be necessary, but that is it.
> Log4j 1 is EOL and should stay that way.
> 
> Ralph
> 
> 
> 
>> On Dec 24, 2021, at 9:47 AM, Ralph Goers  wrote:
>> 
>> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 
>> was released on May 26, 2012. The last commit was to update the 
>> web site 7 years ago. The changes.xml file shows there were commits up to 
>> sometime in 2012, all of which were performed by Gary Gregory 
>> and Christian Grobmeier who ironically both voted no to opening the repo 
>> back up. 
>> 
>> The point of this history is to point out that the project essentially died 
>> in 2012. We simply acknowledged it in 2015.
>> 
>> So now we have voted to open the repo. The question then becomes what to do 
>> next and going forward. I see several options:
>> 
>> 1. Create a README.md that publishes the projects EOL status and do nothing 
>> else.
>> 2. Create a README.md that says the project is EOL and no further big fixes 
>> or enhancements will be made but 1.2.18 was a special 
>>   circumstance. Perform ONLY the following work for 1.2.18:
>>   a.  Make the build work with a modern version of Maven.
>>   b.  Fix the Java version bug.
>>   c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>>   d.  Fix CVE-2019-17571
>>   The expectation is that the above would address the actual issues and not 
>> just remove classes.
>>   Do NOT perform a release of any kind.
>> 3. Option 2 but only perform a source release.
>> 4. Option 2 but perform a full release.
>> 5. Option 4 but allow development to continue, including bug fixes and 
>> enhancements.
>> 
>> I personally can see valid reasons to do any of the above.  I have my own 
>> opinion on this but I will post that in a reply to this discussion kickoff.
>> 
>> If you have other proposals feel free to state them.  
>> 
>> This discussion will be followed up by a vote thread if necessary.
>> 
>> Ralph
>> 
>> 
>> 
> 

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Gary Gregory]

Excellent info, thank you Ralph!

Gary

On Fri, Dec 24, 2021 at 1:06 PM Ralph Goers 
wrote:

> As this falls into a “procedural issue” from
> https://www.apache.org/foundation/voting.html I used
>
> Votes on procedural issues follow the common format of majority rule
> unless otherwise stated. That is, if there
> are more favourable votes than unfavourable ones, the issue is considered
> to have passed -- regardless of the
> number of votes in each category. (If the number of votes seems too small
> to be representative of a community
> consensus, the issue is typically not pursued. However, see the
> description of lazy consensus for a modifying
> factor.)
>
> I cut the vote off because I specifically sent an email to the private
> list asking people to vote last night and most
> of those who hadn’t voted haven’t haven’t participated in PMC activities
> in quite a while or, in one case, is focused
> primarily on a non-Java project.
>
> Ralph
>
> > On Dec 24, 2021, at 10:25 AM, Gary Gregory 
> wrote:
> >
> > Vladimir: It is traditional for the person who called the VOTE to tally
> the
> > VOTE which was only started 19 hours ago. Is 19 hours the way you
> normally
> > run VOTE threads at JMeter? Please do not attempt to cut VOTEs short to
> > force your agenda. People change their minds sometimes.
> >
> > PMC: The repo VOTE thread did not specify the rules for -1/+1: Is a -1 a
> > VETO or does the VOTE follow RELEASE rules? This is obviously not a
> RELEASE
> > though. It's also not a LAZY CONSENSUS VOTE. Sorry to be pedantic, but
> what
> > kind of Apache voting [1] applies to the VOTE thread?
> >
> > Gary
> > [1] https://www.apache.org/foundation/voting.html
> >
> >
> > On Fri, Dec 24, 2021 at 12:00 PM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >
> >> AFAIK only PMC members have binding votes.
> >>
> >> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC
> members
> >> of Logging as per
> >> https://people.apache.org/phonebook.html?project=logging
> >>
> >> So the updated summary is
> >>
> >> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> >> Sicker, Ron Grabowski, and Remko Popma
> >> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> >> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> >> Volkan Yazici, Vladimir Sitnikov
> >>
> >> Vladimir
> >>
>
>

Re: [DISCUSS] The future of Log4j 1.x

[Ralph Goers]

If I were to vote today it would probably be for option 1. I had a discussion 
with another ASF member yesterday who reminded me that in projects 
like Tomcat EOL means EOL. Once that date is hit under no circumstances will 
they issue a new release.

However, I understand that there is a difference between Log4j and Tomcat. 
Tomcat 4 vs 5 would not have been a completely new and 
incompatible architecture as Log4j 2 was. On the other hand I created the 
compatibility bridge 2 years ago and it is quite clear that some of the 
people looking to fix Log4j 1 have no idea it exists and/or have never tried 
it. My preference would be to focus on fixing whatever issues are found 
in that. 

Options 2 & 3 are interesting because they indicate that the project is still 
EOL. But they don’t really help anyone much. So if any work is done on 
the Log4j 1 code base I would generally agree that option 4 is the best choice.

I am also -1 on option 5. If option 4 is chosen it is possible I could be 
persuaded to do another CVE release should one be necessary, but that is it.
Log4j 1 is EOL and should stay that way.

Ralph



> On Dec 24, 2021, at 9:47 AM, Ralph Goers  wrote:
> 
> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 was 
> released on May 26, 2012. The last commit was to update the 
> web site 7 years ago. The changes.xml file shows there were commits up to 
> sometime in 2012, all of which were performed by Gary Gregory 
> and Christian Grobmeier who ironically both voted no to opening the repo back 
> up. 
> 
> The point of this history is to point out that the project essentially died 
> in 2012. We simply acknowledged it in 2015.
> 
> So now we have voted to open the repo. The question then becomes what to do 
> next and going forward. I see several options:
> 
> 1. Create a README.md that publishes the projects EOL status and do nothing 
> else.
> 2. Create a README.md that says the project is EOL and no further big fixes 
> or enhancements will be made but 1.2.18 was a special 
>circumstance. Perform ONLY the following work for 1.2.18:
>a.  Make the build work with a modern version of Maven.
>b.  Fix the Java version bug.
>c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>d.  Fix CVE-2019-17571
>The expectation is that the above would address the actual issues and not 
> just remove classes.
>Do NOT perform a release of any kind.
> 3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
> 5. Option 4 but allow development to continue, including bug fixes and 
> enhancements.
> 
> I personally can see valid reasons to do any of the above.  I have my own 
> opinion on this but I will post that in a reply to this discussion kickoff.
> 
> If you have other proposals feel free to state them.  
> 
> This discussion will be followed up by a vote thread if necessary.
> 
> Ralph
> 
> 
> 

Re: [DISCUSS] The future of Log4j 1.x

[Ralph Goers]

> On Dec 24, 2021, at 10:05 AM, Gary Gregory  wrote:
> 
>> 
> 
> What happens to the new repo Ralph created, will it just be deleted?
> 

The request was to delete that repo. The request was to rename apache/log4j to 
apache/logging-log4j1, 
which is the same name as the repo I created. 

Ralph

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

As this falls into a “procedural issue” from 
https://www.apache.org/foundation/voting.html I used 

Votes on procedural issues follow the common format of majority rule unless 
otherwise stated. That is, if there 
are more favourable votes than unfavourable ones, the issue is considered to 
have passed -- regardless of the 
number of votes in each category. (If the number of votes seems too small to be 
representative of a community 
consensus, the issue is typically not pursued. However, see the description of 
lazy consensus for a modifying 
factor.)

I cut the vote off because I specifically sent an email to the private list 
asking people to vote last night and most 
of those who hadn’t voted haven’t haven’t participated in PMC activities in 
quite a while or, in one case, is focused 
primarily on a non-Java project.

Ralph

> On Dec 24, 2021, at 10:25 AM, Gary Gregory  wrote:
> 
> Vladimir: It is traditional for the person who called the VOTE to tally the
> VOTE which was only started 19 hours ago. Is 19 hours the way you normally
> run VOTE threads at JMeter? Please do not attempt to cut VOTEs short to
> force your agenda. People change their minds sometimes.
> 
> PMC: The repo VOTE thread did not specify the rules for -1/+1: Is a -1 a
> VETO or does the VOTE follow RELEASE rules? This is obviously not a RELEASE
> though. It's also not a LAZY CONSENSUS VOTE. Sorry to be pedantic, but what
> kind of Apache voting [1] applies to the VOTE thread?
> 
> Gary
> [1] https://www.apache.org/foundation/voting.html
> 
> 
> On Fri, Dec 24, 2021 at 12:00 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> 
>> AFAIK only PMC members have binding votes.
>> 
>> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
>> of Logging as per
>> https://people.apache.org/phonebook.html?project=logging
>> 
>> So the updated summary is
>> 
>> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
>> Sicker, Ron Grabowski, and Remko Popma
>> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
>> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
>> Volkan Yazici, Vladimir Sitnikov
>> 
>> Vladimir
>> 

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[sebb]

On Fri, 24 Dec 2021 at 17:57, Vladimir Sitnikov
 wrote:
>
> 1) I stand corrected, I misinterpreted the phonebook (I watched on bold
> records only), so your calculation was correct. Sorry for that.

Entries in bold are ASF members.

> > which was only started 19 hours ago
>
> "vote count != consensus", and the key we seek is consensus (e.g.
> agreement).
> For instance, if the tally is like +5 -2, then, it is up to somebody (vote
> starter?)
> to decide if there's an agreement indeed.
>
> >VOTE threads at JMeter
>
> (un)fortunately, there are only a few active committers/PMCs, so we just
> vote fast, and we know no new votes would appear.
>
> >voting [1] applies to the VOTE thread?
>
> I guess it is up to the one who starts the thread.
> If you mention "lazy consensus", it becomes lazy.
> If you mention "votes are open for 365 days", then it becomes 365 day vote
> :)
>
> Vladimir

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Vladimir Sitnikov]

>Last I recalled I was a PMC member of this group.
>Probably check the link again you sent

Sorry for that, I misinterpreted the data (I watched bold records only for
unknown reasons).
The initial calculation by Ralph was right.

Vladimir

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Vladimir Sitnikov]

1) I stand corrected, I misinterpreted the phonebook (I watched on bold
records only), so your calculation was correct. Sorry for that.

> which was only started 19 hours ago

"vote count != consensus", and the key we seek is consensus (e.g.
agreement).
For instance, if the tally is like +5 -2, then, it is up to somebody (vote
starter?)
to decide if there's an agreement indeed.

>VOTE threads at JMeter

(un)fortunately, there are only a few active committers/PMCs, so we just
vote fast, and we know no new votes would appear.

>voting [1] applies to the VOTE thread?

I guess it is up to the one who starts the thread.
If you mention "lazy consensus", it becomes lazy.
If you mention "votes are open for 365 days", then it becomes 365 day vote
:)

Vladimir

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[sebb]

On Fri, 24 Dec 2021 at 17:03, Carter Kozak  wrote:
>
> You can find the PMC list here: 
> https://people.apache.org/phonebook.html?pmc=logging

AFAIK that uses the LDAP group.

The official list is derived from committee-info.txt as shown by Whimsy:
https://whimsy.apache.org/roster/committee/logging

This should normally be the same, but there are sometimes differences
(usually accidental, but sometimes deliberate).

> On Fri, Dec 24, 2021, at 11:59, Vladimir Sitnikov wrote:
> > AFAIK only PMC members have binding votes.
> >
> > AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
> > of Logging as per
> > https://people.apache.org/phonebook.html?project=logging
> >
> > So the updated summary is
> >
> > Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> > Sicker, Ron Grabowski, and Remko Popma
> > Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> > A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> > Volkan Yazici, Vladimir Sitnikov
> >
> > Vladimir
> >

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

On Fri, Dec 24, 2021, at 17:59, Vladimir Sitnikov wrote:
> AFAIK only PMC members have binding votes.
>
> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
> of Logging as per
> https://people.apache.org/phonebook.html?project=logging
>
> So the updated summary is
>
> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> Sicker, Ron Grabowski, and Remko Popma
> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> Volkan Yazici, Vladimir Sitnikov

Last I recalled I was a PMC member of this group.
Probably check the link again you sent. 

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

Thank you very much Ralph for compiling this list.

On Fri, Dec 24, 2021, at 17:47, Ralph Goers wrote:
> 1. Create a README.md that publishes the projects EOL status and do 
> nothing else.
> 2. Create a README.md that says the project is EOL and no further big 
> fixes or enhancements will be made but 1.2.18 was a special 
> circumstance. Perform ONLY the following work for 1.2.18:
> a.  Make the build work with a modern version of Maven.
> b.  Fix the Java version bug.
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> d.  Fix CVE-2019-17571
> The expectation is that the above would address the actual issues 
> and not just remove classes.
> Do NOT perform a release of any kind.
> 3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
> 5. Option 4 but allow development to continue, including bug fixes and 
> enhancements.

I am thinking option 1 is the best. We should improve log4j2 instead of wasting 
time to software which was last. updated in what, 2012?

However, I can see that there is some users who want to fix serious issues 
because they have reasons.

I would be fine with 2, if:

 - we clearly mark it EOL and tell this is a security patch for those who still 
couldn't upgrade
 - we promote to work on log4j2 bridge et al, if someone is willing to 
contribute, and helping writing migration guides
 - we allow all commits which makes the build easier and fixes (critical) 
issues. No more features which could lead to a version bump to 1.3, which is 
already taken by a failed attempt to upgrade

I am OK with option 4. The build is to complicated for anybody outside the 
developer list to make it happen. If we upgrade, we need to help users further.

Here is a new option.

Assuming we can make it a 1.2.18 and assuming we find out there is >=2 people 
willing to develop this further by ~mid 2022, we vote again if we continue this 
project. 

Only with a committed community we don't have to close it down again. Please 
take also in mind, that there is a competing logging project which developed 
the 1.2.x code base further. This will also add tensions.

Cheers
Christian 


>
> I personally can see valid reasons to do any of the above.  I have my 
> own opinion on this but I will post that in a reply to this discussion 
> kickoff.
>
> If you have other proposals feel free to state them.  
>
> This discussion will be followed up by a vote thread if necessary.
>
> Ralph

Re: [DISCUSS] The future of Log4j 1.x

[Vladimir Sitnikov]

>a.  Make the build work with a modern version of Maven.
>b.  Fix the Java version bug.
>c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>d.  Fix CVE-2019-17571
>allow development to continue, including bug fixes and enhancements

+1 to all that, including new source+binary releases as the changes are
merged.

On top of that, I would suggest dropping EOL notice and using something like
"Supported on best effort basis" or "Development ceased".

Vladimir

Re: [DISCUSS] The future of Log4j 1.x

[Gary Gregory]

On Fri, Dec 24, 2021 at 12:13 PM Carter Kozak  wrote:

> > Sorry to be pedantic, but what Apache rules apply to the previous
> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
> > It should be telling, not ironic, that the last two contributors to
> Log4j 1 that are still here voted -1
>
> This is a great point which I hadn't realized myself. For what it's worth,
> I would consider _my_ vote with much less weight than those who have
> actually contributed to and maintained the log4j-1 project.
>

Let's not do that! ;-) Don't weigh your vote for not having had to suffer
through log4j 1 releases, DLLs and all ;-)

Gary


> -ck
>
> On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
> > On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers  >
> > wrote:
> >
> > > As we all know Log4j 1.x reached end of life in August 2015. Log4j
> 1.2.17
> > > was released on May 26, 2012. The last commit was to update the
> > > web site 7 years ago. The changes.xml file shows there were commits up
> to
> > > sometime in 2012, all of which were performed by Gary Gregory
> > > and Christian Grobmeier who ironically both voted no to opening the
> repo
> > > back up.
> >
> >
> > Note that the repo DISCUSS/VOTE thread seemed informal because it did
> > specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow
> RELEASE
> > rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
> > what Apache rules apply to the previous DISCUSS/VOTE thread?
> >
> > It should be telling, not ironic, that the last two contributors to
> Log4j 1
> > that are still here voted -1, but, if, big if, we (1) move fw the repo
> and
> > (2) then w a release... I'll opine ;-)
> >
> >
> > >
> > >
> > > The point of this history is to point out that the project essentially
> > > died in 2012. We simply acknowledged it in 2015.
> > >
> > > So now we have voted to open the repo. The question then becomes what
> to
> > > do next and going forward. I see several options:
> > >
> >
> > What happens to the new repo Ralph created, will it just be deleted?
> >
> >
> > >
> > > 1. Create a README.md that publishes the projects EOL status and do
> > > nothing else.
> > >
> > Fine with me.
> >
> >
> > > 2. Create a README.md that says the project is EOL and no further big
> > > fixes or enhancements will be made but 1.2.18 was a special
> > > circumstance. Perform ONLY the following work for 1.2.18:
> > > a.  Make the build work with a modern version of Maven.
> > >
> > If we move fw w the repo, this seems like a no-brainer requirement IMO.
> >
> >
> > > b.  Fix the Java version bug.
> > >
> > Not sure what that one is, but If we move fw w the repo, OK.
> >
> > c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> > >
> > If we move fw w the repo, OK
> >
> >
> > > d.  Fix CVE-2019-17571
> > > The expectation is that the above would address the actual issues
> and
> > > not just remove classes.
> > >
> > If we move fw w the repo, OK.
> >
> >
> > > Do NOT perform a release of any kind.
> > >
> > 3. Option 2 but only perform a source release.
> > > 4. Option 2 but perform a full release.
> > >
> > Seems like the better solution b/w 3 and 4, a source only feels like a
> > tease if not worse.
> >
> >
> > > 5. Option 4 but allow development to continue, including bug fixes and
> > > enhancements.
> > >
> > -1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.
> >
> > Thank you Ralph but putting this list together! :-)
> > Gary
> >
> >
> > >
> > > I personally can see valid reasons to do any of the above.  I have my
> own
> > > opinion on this but I will post that in a reply to this discussion
> kickoff.
> > >
> > > If you have other proposals feel free to state them.
> > >
> > > This discussion will be followed up by a vote thread if necessary.
> > >
> > > Ralph
> > >
> > >
> > >
> >
>

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

On Fri, Dec 24, 2021, at 18:12, Carter Kozak wrote:
>> Sorry to be pedantic, but what Apache rules apply to the previous 
>> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
>> It should be telling, not ironic, that the last two contributors to Log4j 1 
>> that are still here voted -1
>
> This is a great point which I hadn't realized myself. For what it's 
> worth, I would consider _my_ vote with much less weight than those who 
> have actually contributed to and maintained the log4j-1 project.

There is no log4j1 or log4j2 community. There is only one ASF Logging 
community, which includes all committers from all the logging projects.

I have contributed to log4j1, but our votes weight the same. You are on the PMC 
because other PMC members trusted you, so do I. I trust you and believe your 
raise opinions to the best of the project.

We had this kind of discussion in our project history: "I had more commits, why 
doesn't it give me more weight in decisions". It almost killed this project 
years ago and led to many frustrations.

I hope I didn't sound like a teacher too much, but working here at that time 
made me very sensitive to this topic, so I had to write this.

Cheers!

>
> -ck
>
> On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
>> On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers 
>> wrote:
>> 
>> > As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
>> > was released on May 26, 2012. The last commit was to update the
>> > web site 7 years ago. The changes.xml file shows there were commits up to
>> > sometime in 2012, all of which were performed by Gary Gregory
>> > and Christian Grobmeier who ironically both voted no to opening the repo
>> > back up.
>> 
>> 
>> Note that the repo DISCUSS/VOTE thread seemed informal because it did
>> specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow RELEASE
>> rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
>> what Apache rules apply to the previous DISCUSS/VOTE thread?
>> 
>> It should be telling, not ironic, that the last two contributors to Log4j 1
>> that are still here voted -1, but, if, big if, we (1) move fw the repo and
>> (2) then w a release... I'll opine ;-)
>> 
>> 
>> >
>> >
>> > The point of this history is to point out that the project essentially
>> > died in 2012. We simply acknowledged it in 2015.
>> >
>> > So now we have voted to open the repo. The question then becomes what to
>> > do next and going forward. I see several options:
>> >
>> 
>> What happens to the new repo Ralph created, will it just be deleted?
>> 
>> 
>> >
>> > 1. Create a README.md that publishes the projects EOL status and do
>> > nothing else.
>> >
>> Fine with me.
>> 
>> 
>> > 2. Create a README.md that says the project is EOL and no further big
>> > fixes or enhancements will be made but 1.2.18 was a special
>> > circumstance. Perform ONLY the following work for 1.2.18:
>> > a.  Make the build work with a modern version of Maven.
>> >
>> If we move fw w the repo, this seems like a no-brainer requirement IMO.
>> 
>> 
>> > b.  Fix the Java version bug.
>> >
>> Not sure what that one is, but If we move fw w the repo, OK.
>> 
>> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>> >
>> If we move fw w the repo, OK
>> 
>> 
>> > d.  Fix CVE-2019-17571
>> > The expectation is that the above would address the actual issues and
>> > not just remove classes.
>> >
>> If we move fw w the repo, OK.
>> 
>> 
>> > Do NOT perform a release of any kind.
>> >
>> 3. Option 2 but only perform a source release.
>> > 4. Option 2 but perform a full release.
>> >
>> Seems like the better solution b/w 3 and 4, a source only feels like a
>> tease if not worse.
>> 
>> 
>> > 5. Option 4 but allow development to continue, including bug fixes and
>> > enhancements.
>> >
>> -1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.
>> 
>> Thank you Ralph but putting this list together! :-)
>> Gary
>> 
>> 
>> >
>> > I personally can see valid reasons to do any of the above.  I have my own
>> > opinion on this but I will post that in a reply to this discussion kickoff.
>> >
>> > If you have other proposals feel free to state them.
>> >
>> > This discussion will be followed up by a vote thread if necessary.
>> >
>> > Ralph
>> >
>> >
>> >
>>

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Gary Gregory]

Vladimir: It is traditional for the person who called the VOTE to tally the
VOTE which was only started 19 hours ago. Is 19 hours the way you normally
run VOTE threads at JMeter? Please do not attempt to cut VOTEs short to
force your agenda. People change their minds sometimes.

PMC: The repo VOTE thread did not specify the rules for -1/+1: Is a -1 a
VETO or does the VOTE follow RELEASE rules? This is obviously not a RELEASE
though. It's also not a LAZY CONSENSUS VOTE. Sorry to be pedantic, but what
kind of Apache voting [1] applies to the VOTE thread?

Gary
[1] https://www.apache.org/foundation/voting.html


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

> AFAIK only PMC members have binding votes.
>
> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
> of Logging as per
> https://people.apache.org/phonebook.html?project=logging
>
> So the updated summary is
>
> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> Sicker, Ron Grabowski, and Remko Popma
> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> Volkan Yazici, Vladimir Sitnikov
>
> Vladimir
>

Re: [DISCUSS] The future of Log4j 1.x

[Carter Kozak]

> Sorry to be pedantic, but what Apache rules apply to the previous 
> DISCUSS/VOTE thread?

There's no need to apologize, the rules exist for a reason!

> It should be telling, not ironic, that the last two contributors to Log4j 1 
> that are still here voted -1

This is a great point which I hadn't realized myself. For what it's worth, I 
would consider _my_ vote with much less weight than those who have actually 
contributed to and maintained the log4j-1 project.

-ck

On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
> On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers 
> wrote:
> 
> > As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> > was released on May 26, 2012. The last commit was to update the
> > web site 7 years ago. The changes.xml file shows there were commits up to
> > sometime in 2012, all of which were performed by Gary Gregory
> > and Christian Grobmeier who ironically both voted no to opening the repo
> > back up.
> 
> 
> Note that the repo DISCUSS/VOTE thread seemed informal because it did
> specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow RELEASE
> rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
> what Apache rules apply to the previous DISCUSS/VOTE thread?
> 
> It should be telling, not ironic, that the last two contributors to Log4j 1
> that are still here voted -1, but, if, big if, we (1) move fw the repo and
> (2) then w a release... I'll opine ;-)
> 
> 
> >
> >
> > The point of this history is to point out that the project essentially
> > died in 2012. We simply acknowledged it in 2015.
> >
> > So now we have voted to open the repo. The question then becomes what to
> > do next and going forward. I see several options:
> >
> 
> What happens to the new repo Ralph created, will it just be deleted?
> 
> 
> >
> > 1. Create a README.md that publishes the projects EOL status and do
> > nothing else.
> >
> Fine with me.
> 
> 
> > 2. Create a README.md that says the project is EOL and no further big
> > fixes or enhancements will be made but 1.2.18 was a special
> > circumstance. Perform ONLY the following work for 1.2.18:
> > a.  Make the build work with a modern version of Maven.
> >
> If we move fw w the repo, this seems like a no-brainer requirement IMO.
> 
> 
> > b.  Fix the Java version bug.
> >
> Not sure what that one is, but If we move fw w the repo, OK.
> 
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> >
> If we move fw w the repo, OK
> 
> 
> > d.  Fix CVE-2019-17571
> > The expectation is that the above would address the actual issues and
> > not just remove classes.
> >
> If we move fw w the repo, OK.
> 
> 
> > Do NOT perform a release of any kind.
> >
> 3. Option 2 but only perform a source release.
> > 4. Option 2 but perform a full release.
> >
> Seems like the better solution b/w 3 and 4, a source only feels like a
> tease if not worse.
> 
> 
> > 5. Option 4 but allow development to continue, including bug fixes and
> > enhancements.
> >
> -1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.
> 
> Thank you Ralph but putting this list together! :-)
> Gary
> 
> 
> >
> > I personally can see valid reasons to do any of the above.  I have my own
> > opinion on this but I will post that in a reply to this discussion kickoff.
> >
> > If you have other proposals feel free to state them.
> >
> > This discussion will be followed up by a vote thread if necessary.
> >
> > Ralph
> >
> >
> >
> 

Re: [DISCUSS] The future of Log4j 1.x

[Gary Gregory]

On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers 
wrote:

> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> was released on May 26, 2012. The last commit was to update the
> web site 7 years ago. The changes.xml file shows there were commits up to
> sometime in 2012, all of which were performed by Gary Gregory
> and Christian Grobmeier who ironically both voted no to opening the repo
> back up.


Note that the repo DISCUSS/VOTE thread seemed informal because it did
specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow RELEASE
rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
what Apache rules apply to the previous DISCUSS/VOTE thread?

It should be telling, not ironic, that the last two contributors to Log4j 1
that are still here voted -1, but, if, big if, we (1) move fw the repo and
(2) then w a release... I'll opine ;-)


>
>
> The point of this history is to point out that the project essentially
> died in 2012. We simply acknowledged it in 2015.
>
> So now we have voted to open the repo. The question then becomes what to
> do next and going forward. I see several options:
>

What happens to the new repo Ralph created, will it just be deleted?


>
> 1. Create a README.md that publishes the projects EOL status and do
> nothing else.
>
Fine with me.


> 2. Create a README.md that says the project is EOL and no further big
> fixes or enhancements will be made but 1.2.18 was a special
> circumstance. Perform ONLY the following work for 1.2.18:
> a.  Make the build work with a modern version of Maven.
>
If we move fw w the repo, this seems like a no-brainer requirement IMO.


> b.  Fix the Java version bug.
>
Not sure what that one is, but If we move fw w the repo, OK.

c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>
If we move fw w the repo, OK


> d.  Fix CVE-2019-17571
> The expectation is that the above would address the actual issues and
> not just remove classes.
>
If we move fw w the repo, OK.


> Do NOT perform a release of any kind.
>
3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
>
Seems like the better solution b/w 3 and 4, a source only feels like a
tease if not worse.


> 5. Option 4 but allow development to continue, including bug fixes and
> enhancements.
>
-1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.

Thank you Ralph but putting this list together! :-)
Gary


>
> I personally can see valid reasons to do any of the above.  I have my own
> opinion on this but I will post that in a reply to this discussion kickoff.
>
> If you have other proposals feel free to state them.
>
> This discussion will be followed up by a vote thread if necessary.
>
> Ralph
>
>
>

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Carter Kozak]

You can find the PMC list here: 
https://people.apache.org/phonebook.html?pmc=logging

On Fri, Dec 24, 2021, at 11:59, Vladimir Sitnikov wrote:
> AFAIK only PMC members have binding votes.
> 
> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
> of Logging as per
> https://people.apache.org/phonebook.html?project=logging
> 
> So the updated summary is
> 
> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> Sicker, Ron Grabowski, and Remko Popma
> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> Volkan Yazici, Vladimir Sitnikov
> 
> Vladimir
> 

Re: [DISCUSS] The future of Log4j 1.x

[Carter Kozak]

I would agree directionally with option 1 or option 4.

Making changes without pushing binary artifacts to maven central (options 2 and 
3) is unlikely to do much good for the types of projects which still use 
log4j1. Option 5 is a hard no from me, my time is already too constrained, 
there are better options, and the architecture limits substantive improvements.

-ck

On Fri, Dec 24, 2021, at 11:47, Ralph Goers wrote:
> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 was 
> released on May 26, 2012. The last commit was to update the 
> web site 7 years ago. The changes.xml file shows there were commits up to 
> sometime in 2012, all of which were performed by Gary Gregory 
> and Christian Grobmeier who ironically both voted no to opening the repo back 
> up. 
> 
> The point of this history is to point out that the project essentially died 
> in 2012. We simply acknowledged it in 2015.
> 
> So now we have voted to open the repo. The question then becomes what to do 
> next and going forward. I see several options:
> 
> 1. Create a README.md that publishes the projects EOL status and do nothing 
> else.
> 2. Create a README.md that says the project is EOL and no further big fixes 
> or enhancements will be made but 1.2.18 was a special 
> circumstance. Perform ONLY the following work for 1.2.18:
> a.  Make the build work with a modern version of Maven.
> b.  Fix the Java version bug.
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> d.  Fix CVE-2019-17571
> The expectation is that the above would address the actual issues and not 
> just remove classes.
> Do NOT perform a release of any kind.
> 3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
> 5. Option 4 but allow development to continue, including bug fixes and 
> enhancements.
> 
> I personally can see valid reasons to do any of the above.  I have my own 
> opinion on this but I will post that in a reply to this discussion kickoff.
> 
> If you have other proposals feel free to state them.  
> 
> This discussion will be followed up by a vote thread if necessary.
> 
> Ralph
> 
> 
> 

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Vladimir Sitnikov]

AFAIK only PMC members have binding votes.

AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
of Logging as per
https://people.apache.org/phonebook.html?project=logging

So the updated summary is

Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
Sicker, Ron Grabowski, and Remko Popma
Binding -1 votes were received from Gary Gregory and Christian Grobmeier
A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
Volkan Yazici, Vladimir Sitnikov

Vladimir

[DISCUSS] The future of Log4j 1.x

[Ralph Goers]

As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 was 
released on May 26, 2012. The last commit was to update the 
web site 7 years ago. The changes.xml file shows there were commits up to 
sometime in 2012, all of which were performed by Gary Gregory 
and Christian Grobmeier who ironically both voted no to opening the repo back 
up. 

The point of this history is to point out that the project essentially died in 
2012. We simply acknowledged it in 2015.

So now we have voted to open the repo. The question then becomes what to do 
next and going forward. I see several options:

1. Create a README.md that publishes the projects EOL status and do nothing 
else.
2. Create a README.md that says the project is EOL and no further big fixes or 
enhancements will be made but 1.2.18 was a special 
circumstance. Perform ONLY the following work for 1.2.18:
a.  Make the build work with a modern version of Maven.
b.  Fix the Java version bug.
c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
d.  Fix CVE-2019-17571
The expectation is that the above would address the actual issues and not 
just remove classes.
Do NOT perform a release of any kind.
3. Option 2 but only perform a source release.
4. Option 2 but perform a full release.
5. Option 4 but allow development to continue, including bug fixes and 
enhancements.

I personally can see valid reasons to do any of the above.  I have my own 
opinion on this but I will post that in a reply to this discussion kickoff.

If you have other proposals feel free to state them.  

This discussion will be followed up by a vote thread if necessary.

Ralph

[RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

I am closing this vote as I believe all PMC members who desire to vote on this 
have done so. 

The vote to perform the following steps passes:

1. Delete the apache/logging-log4j1 repo I created last night.
2. Divorce the apache/log4j repo from SVN.
3. Rename apache/log4j to apache/logging-log4j1.
4. Create a branch named “main” from the v1_2_17 tag.
5. Make main the default branch in GitHub.

Binding +1 votes were received from Carter Kozak, Ralph Goers, Dominik Psenner, 
Matt Sicker, Ron Grabowski, Robert Middleton, Remko Popma, and Volkan Yazici
Binding -1 votes were received from Gary Gregory and Christian Grobmeier
A non-binding +1 vote was received from Vladimir Sitnikov 

I will update https://issues.apache.org/jira/browse/INFRA-22654 
 accordingly.

Ralph

Re: RELEASE-NOTES.md

[Volkan Yazıcı]

Hrm... Via `announcement.vm` I guess... I see. Thanks for the pointer.

On Fri, Dec 24, 2021 at 3:01 PM Apache  wrote:

> The release notes file is generated for every release.
>
> Ralph
>
> > On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
> >
> > Is this file still relevant? If not, may I simply delete it? If it is,
> mind
> > somebody explaining what to do with it? How shall we use it in the
> presence
> > of `changes.xml`?
> >
> > -- Forwarded message -
> > From: Kristjan Esperanto 
> > Date: Sun, Dec 19, 2021 at 12:08 PM
> > Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
> > To: apache/logging-log4j2 
> > Cc: Subscribed 
> >
> >
> > It's a minor detail, but I didn't find any reference to the release
> history
> > in the repository.
> > --
> > You can view, comment on, or merge this pull request online at:
> >
> >  https://github.com/apache/logging-log4j2/pull/642
> > Commit Summary
> >
> >   - 89ff650
> >   <
> https://github.com/apache/logging-log4j2/pull/642/commits/89ff6508f735e3e422abbf5b221a5ff0980c22c9
> >
> >   Add Link to Release History
> >
> > File Changes
> >
> > (1 file )
> >
> >   - *M* RELEASE-NOTES.md
> >   <
> https://github.com/apache/logging-log4j2/pull/642/files#diff-7d8a453165f16d910a0937bf01782607cafc77fd7f42b443aff0cd02725848d7
> >
> >   (4)
> >
> > Patch Links:
> >
> >   - https://github.com/apache/logging-log4j2/pull/642.patch
> >   - https://github.com/apache/logging-log4j2/pull/642.diff
> >
> > —
> > Reply to this email directly, view it on GitHub
> > , or unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/AAARTSKH4JEGNONQTMPORJ3URW4KPANCNFSM5KLYIE2Q
> >
> > .
> > You are receiving this because you are subscribed to this thread.Message
> > ID: 
>
>
>

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hi

On Fri, Dec 24, 2021, at 06:29, Vladimir Sitnikov wrote:
> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?

I was not aware of that, but the way you discussed looked like it was helpful 
to send that link.

> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?

No. We discuss, I listen to arguments and/or give mine and then we have a vote. 
A vote is already done and I can express my opinion as I wish too.

This is also not the tone of an email we send around to each other here.

> Are there another viable alternatives?

Yes.

> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.

if done wrong, we commit ourselves to maintain an EOL product and give wrong 
expectations. I want this PMC to be very sure about what we do and careful 
about how our actions look to the public.

I will not agree to anything just because you think it is right. We all need to 
think it is right. How can we know, you actually plan to work on it after we 
open it? Send in patches, we review, and then we can always make it up for 
writes and apply them. As an ASF fellow you know how this works.

Thanks,
Christian

>
> Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

Hi Vladimir,

On Fri, Dec 24, 2021, at 13:51, Vladimir Sitnikov wrote:
> Dominik,
>
> Are you willing to add committers and PMC members to the log4j 1.x
> community?

if we add people, then we add it to the logging project. There is no separate 
log4j/log4php whatever community. We are one community.

> If you forbid issues and pull requests, then it goes against the idea of
> adding new commuters and PMC members for 1.x.

That's why I think we should have voted on the goal first, and then discuss 
technical details.
At the moment I think the PMC is pretty much 1.x stays EOL at this point of 
time.

> How do you expect to nominate committers and PMC members if you
> forbid pull requests, forbid non-CVE changes, and so on?
>
> How do you expect to nominate committers and PMC members if you
> want to mention EOL all over the place?

It was already mentioned 2015. You can send patches, become a committer to ASF 
Logging and when everybody sees there is real interest and real developer 
capacity behind this idea, then maybe we as community decide to make a separate 
product.

Please use another email thread than the vote thread to discuss these things 
anyway, it makes it harder to count the votes.

Thank you.

Christian

> I would rather use "log4j 1.x is feature complete, so no new features are
> expected to appear"
> On the other hand, it should be perfectly fine to add new tests, fix
> security issues,
> fix other issues (e.g. NPEs).
>
> Vladimir

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Gary Gregory]

Hi Volkan,
Nothing is ideal or great about a Log4j1 revival IMO. I still see more cons
than pros. I understand that some people choose to stay stuck on it despite
the 2015 EOL marker. I wish I'd joined that debate club in high school so I
could better articulate my arguments for pulling these folks of the Log4j 1
doldrums.

So, speaking of not ideal, we might consider EOL'ing the old repo itself
and saying you have x months to move your stuff, the component is EOL after
all and will remain so even though we are doing a CVE+ release (CVE + the
2.x kind of changes that are not 1.x CVEs) from the new repo. A new repo
will make people think about what PRs matter and what is throwaway or just
cruft. It might make things less confusing for GitHub visitors that find a
new repo that is not full of old stuff that will never come to life, EOL
after all.

It's not ideal but neither is using dead EOL software.

Gary

On Fri, Dec 24, 2021, 03:21 Volkan Yazıcı  wrote:

> Gary, I see that you want to stick to the `logging-log4j1` repo Ralph has
> created. What do you propose for the current `log4j` repo? Will they exist
> next to each other? I think that will be a really confusing setup. Can we
> make a pointer from `log4j` to `logging-log4j` in the README and GitHub
> description?
>
> I agree with stating the goal clearly.
>
> I don't think we will be able to avoid PRs contributing random stuff to
> Log4j. Once we make a 1.2.18 release, Pandora's box will be open. The only
> thing we can do from then on is to share the goal statement with the
> incoming PRs and simply reject them.
>
> On Thu, Dec 23, 2021 at 10:50 PM Gary Gregory 
> wrote:
>
> > -1
> > We just created logging-log4j1 and converted the SVN repo into it, let's
> > stick to that. I even made a commit ;-)
> > I claim it is a good thing to start with a new repo because it creates a
> > tiny bit of friction, for a project that is still End-of-Life after all.
> > Even if it is a bit of friction to bring in old stuff from the old repo,
> > this would provide a kind of effort/value filter.
> > The concurrent consensus I see on the PMC is to fix the one listed CVE on
> > our site plus other fixes in the style of the recent 2.x fixes.
> > Bringing in all of the cruft from the old repo will give the wrong
> > impression that we actually might be merging this or that random fix and
> > feature. Which I claim is not the goal here.
> >
> > I feel we might need an addendum or a subsequent VOTE with a stated goal
> or
> > charter for this repo to only provide CVE fixes (see above). Projects
> > usually have a charter, not components I do not think, but I think we
> > should have one here and put it in front and center in the README.md so
> we
> > can manage expectations for people finding the repo on GitHub.
> >
> > Gary
> >
> > On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
> > wrote:
> >
> > > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has
> > > recommended that we can divorce
> > > the read-only SVN repo from https://github.com/apache/log4j. However,
> it
> > > will not be able to keep the same
> > > name as all Git repos owned by the logging project must start with
> > > “logging-“.
> > >
> > > So this vote is to:
> > > 1. Delete the apache/logging-log4j1 repo I created last night.
> > > 2. Divorce the apache/log4j repo from SVN.
> > > 3. Rename apache/log4j to apache/logging-log4j1.
> > > 4. Create a branch named “main” from the v1_2_17 tag.
> > > 5. Make main the default branch in GitHub.
> > >
> > > While all votes are welcome Infra needs consensus from the PMC on this
> > > vote so the result will separate
> > > binding from non-binding votes.
> > >
> > > Ralph
> > >
> > > PS - I’ve separated this from the previous vote thread since it was
> > mostly
> > > discussion. If you want to discuss
> > > this please prefix the subject with [DISCUSS]
> >
>

Re: RELEASE-NOTES.md

[Apache]

I should have added that you should not delete it.

Ralph

> On Dec 24, 2021, at 7:00 AM, Apache  wrote:
> 
> The release notes file is generated for every release.
> 
> Ralph
> 
>> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
>> 
>> Is this file still relevant? If not, may I simply delete it? If it is, mind
>> somebody explaining what to do with it? How shall we use it in the presence
>> of `changes.xml`?
>> 
>> -- Forwarded message -
>> From: Kristjan Esperanto 
>> Date: Sun, Dec 19, 2021 at 12:08 PM
>> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
>> To: apache/logging-log4j2 
>> Cc: Subscribed 
>> 
>> 
>> It's a minor detail, but I didn't find any reference to the release history
>> in the repository.
>> --
>> You can view, comment on, or merge this pull request online at:
>> 
>> https://github.com/apache/logging-log4j2/pull/642
>> Commit Summary
>> 
>>  - 89ff650
>>  
>> 
>>  Add Link to Release History
>> 
>> File Changes
>> 
>> (1 file )
>> 
>>  - *M* RELEASE-NOTES.md
>>  
>> 
>>  (4)
>> 
>> Patch Links:
>> 
>>  - https://github.com/apache/logging-log4j2/pull/642.patch
>>  - https://github.com/apache/logging-log4j2/pull/642.diff
>> 
>> —
>> Reply to this email directly, view it on GitHub
>> , or unsubscribe
>> 
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: 

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Dominik Psenner]

As PMC member I voted to make the source code available in a git
repository. The git repository and the mailing list are all the tools
needed to prepare contributions and fixes. It allows for easy forking and
contributions to prosper. I would love to see this cause the community to
grow. It would be awesome to see more committers and add additional PMC
members.

As of now, log4j1 is still EOL. By examining future contributions we can
have a discussion about the EOL status in the future.

Lets take one step at a time! To me it is premature to open a public issue
tracker or accepting pull requests from the public. Someone would have to
review them and we would allow allocation of resources in favor of loosing
other opportunities. As said, I voted +1 to provide the tools needed to let
contributors work on contributions.

I encourage you to end the discussions now and to start working on
contributions instead.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Dec 24, 2021, 13:51 Vladimir Sitnikov 
wrote:

> Dominik,
>
> Are you willing to add committers and PMC members to the log4j 1.x
> community?
>
> If you forbid issues and pull requests, then it goes against the idea of
> adding new commuters and PMC members for 1.x.
>
> How do you expect to nominate committers and PMC members if you
> forbid pull requests, forbid non-CVE changes, and so on?
>
> How do you expect to nominate committers and PMC members if you
> want to mention EOL all over the place?
>
> I would rather use "log4j 1.x is feature complete, so no new features are
> expected to appear"
> On the other hand, it should be perfectly fine to add new tests, fix
> security issues,
> fix other issues (e.g. NPEs).
>
> Vladimir
>

Re: RELEASE-NOTES.md

[Apache]

The release notes file is generated for every release.

Ralph

> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
> 
> Is this file still relevant? If not, may I simply delete it? If it is, mind
> somebody explaining what to do with it? How shall we use it in the presence
> of `changes.xml`?
> 
> -- Forwarded message -
> From: Kristjan Esperanto 
> Date: Sun, Dec 19, 2021 at 12:08 PM
> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
> To: apache/logging-log4j2 
> Cc: Subscribed 
> 
> 
> It's a minor detail, but I didn't find any reference to the release history
> in the repository.
> --
> You can view, comment on, or merge this pull request online at:
> 
>  https://github.com/apache/logging-log4j2/pull/642
> Commit Summary
> 
>   - 89ff650
>   
> 
>   Add Link to Release History
> 
> File Changes
> 
> (1 file )
> 
>   - *M* RELEASE-NOTES.md
>   
> 
>   (4)
> 
> Patch Links:
> 
>   - https://github.com/apache/logging-log4j2/pull/642.patch
>   - https://github.com/apache/logging-log4j2/pull/642.diff
> 
> —
> Reply to this email directly, view it on GitHub
> , or unsubscribe
> 
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 

RELEASE-NOTES.md

[Volkan Yazıcı]

Is this file still relevant? If not, may I simply delete it? If it is, mind
somebody explaining what to do with it? How shall we use it in the presence
of `changes.xml`?

-- Forwarded message -
From: Kristjan Esperanto 
Date: Sun, Dec 19, 2021 at 12:08 PM
Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
To: apache/logging-log4j2 
Cc: Subscribed 


It's a minor detail, but I didn't find any reference to the release history
in the repository.
--
You can view, comment on, or merge this pull request online at:

  https://github.com/apache/logging-log4j2/pull/642
Commit Summary

   - 89ff650
   

   Add Link to Release History

File Changes

(1 file )

   - *M* RELEASE-NOTES.md
   

   (4)

Patch Links:

   - https://github.com/apache/logging-log4j2/pull/642.patch
   - https://github.com/apache/logging-log4j2/pull/642.diff

—
Reply to this email directly, view it on GitHub
, or unsubscribe

.
You are receiving this because you are subscribed to this thread.Message
ID: 

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Vladimir Sitnikov]

Dominik,

Are you willing to add committers and PMC members to the log4j 1.x
community?

If you forbid issues and pull requests, then it goes against the idea of
adding new commuters and PMC members for 1.x.

How do you expect to nominate committers and PMC members if you
forbid pull requests, forbid non-CVE changes, and so on?

How do you expect to nominate committers and PMC members if you
want to mention EOL all over the place?

I would rather use "log4j 1.x is feature complete, so no new features are
expected to appear"
On the other hand, it should be perfectly fine to add new tests, fix
security issues,
fix other issues (e.g. NPEs).

Vladimir

Re: Broken CI

[Volkan Yazıcı]

I have simplified(?) the GitHub Actions `build` workflow in `release-2.x`.

Removed `action-surefire-report` usage, hence no extra privileges should be
necessary anymore.
Removed the `-Dmaven.test.failure.ignore=true` flag, hence all tests need
to pass.

On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory  wrote:

> After getting https://github.com/apache/logging-log4j2/pull/646 in what I
> think is a good state, I have no idea if it is safe or not to merge because
> the 1st build GitHub shows is red:
>
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
>
> I don't use GH actions the way we do here and I'm not sure why we need the
> publish test result set when anyone can just look at the build logs.
>
> Gary
>

Re: Broken CI

[Volkan Yazıcı]

`Error: Resource not accessible by integration` failure caused by
`action-surefire-report` trying to access the job triggered by a user who
doesn't have commit rights to the repo. I have actually tried to explain
this in detail in my earlier email. Let me know if that wasn't clear enough.

On Thu, Dec 23, 2021 at 6:34 PM Gary Gregory  wrote:

> I'm not talking about failing tests but about some other build silliness
> that does not feel necessary, for example:
>
> https://github.com/apache/logging-log4j2/runs/4620228443?check_suite_focus=true
>
> Shows:
>
>
> Run scacap/action-surefire-report@v1
> Going to parse results form **/*-reports/TEST-*.xml
> Result: 4015 tests run, 15 skipped, 0 failed.
> Posting status 'completed' with conclusion 'success' to
> https://github.com/apache/logging-log4j2/pull/651 (sha:
> 06c61ddc60b24610fda694aa54f4c1dd2e29ff07)
> Error: Resource not accessible by integration
>
> Gary
>
>
> On Thu, Dec 23, 2021, 10:24 Volkan Yazıcı  wrote:
>
> > Since, there are some tests which occasionally constantly fail, we use
> > `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build
> > with test failures to be marked green. The 3rd party component,
> > `scacap/action-surefire-report@v1`, is used to feed these failures back
> > into GitHub Actions status with some pretty printing. But since the PR is
> > opened by a user who doesn't have commit rights, the 3rd party component
> > fails to mark the failures due to insufficient privileges. In
> > `.github/workflows/main.yml`, I had introduced the `if: github.repository
> > == 'apache/logging-log4j2'` line to work around this, but apparently it
> is
> > broken again.
> >
> > I totally share your frustration, same here. Though sparing time to fix
> > this is pretty difficult nowadays.
> >
> > I also need to confess, in those brief moments of insanity, I contemplate
> > nuking all those flaky tests. This will simplify the CI magic a lot and
> > enhance our confidence in the tests.
> >
> > On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> > wrote:
> >
> > > After getting https://github.com/apache/logging-log4j2/pull/646 in
> what
> > I
> > > think is a good state, I have no idea if it is safe or not to merge
> > because
> > > the 1st build GitHub shows is red:
> > >
> > >
> >
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> > >
> > > I don't use GH actions the way we do here and I'm not sure why we need
> > the
> > > publish test result set when anyone can just look at the build logs.
> > >
> > > Gary
> > >
> >
>

Re: Resurrecting log4j 1.x

[Volkan Yazıcı]

Okay, my mistake, that makes it 3 people.

The PMC is already in the progress of resurrecting 1.x. Once the repo is
up, we will be happy to review and merge your PRs, granted they only target
security vulnerabilities.

On Fri, Dec 24, 2021 at 9:40 AM Andrew Marlow 
wrote:

> On Thu, 23 Dec 2021 at 15:13, Volkan Yazıcı  wrote:
>
> > Vladimir, mind helping us to quantify this "need", please? To the best of
> > my knowledge, nobody has reached out to us with such a request except you
> > and Leo.
>
>
> That's not quite right. A while ago I asked if the RedHat fix could be
> added to log4j-1 to create version 1.2.18. This was to fix
> https://www.cvedetails.com/cve/CVE-2019-17571. RedHat have already
> implemented a fix for this which is included in RHEL. It was pointed out
> then that since log4j-1 is EOL no further releases would be made. I was
> very disappointed. Now people are talking about resurrecting log4j-1 just
> for fixing CVEs I would like people to consider doing this one first
> please.
>
> The Red Hat announcement of their fix can be seen at
> https://access.redhat.com/security/cve/cve-2019-17571
> Back in the day I tracked down their code fix and satisfied myself that it
> does the job. It was a bit of effort to track down but I'm sure Red hat
> would help if we asked them nicely.
>

Re: Resurrecting log4j 1.x

[Andrew Marlow]

On Thu, 23 Dec 2021 at 15:13, Volkan Yazıcı  wrote:

> Vladimir, mind helping us to quantify this "need", please? To the best of
> my knowledge, nobody has reached out to us with such a request except you
> and Leo.


That's not quite right. A while ago I asked if the RedHat fix could be
added to log4j-1 to create version 1.2.18. This was to fix
https://www.cvedetails.com/cve/CVE-2019-17571. RedHat have already
implemented a fix for this which is included in RHEL. It was pointed out
then that since log4j-1 is EOL no further releases would be made. I was
very disappointed. Now people are talking about resurrecting log4j-1 just
for fixing CVEs I would like people to consider doing this one first
please.

The Red Hat announcement of their fix can be seen at
https://access.redhat.com/security/cve/cve-2019-17571
Back in the day I tracked down their code fix and satisfied myself that it
does the job. It was a bit of effort to track down but I'm sure Red hat
would help if we asked them nicely.

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Volkan Yazıcı]

+1

Goal needs to be stated in bold in a README.
Existing PRs (there are 14 as of date) need to be processed.

This 1.x discussion took way more time then it should, IMHO. Let's take the
simplest approach and be done with it. We all agreed to not accept anything
except security fixes. Though we all know there will be incoming PRs, which
we can all do is to reject after pointing to our goal statement.

I am not keen to keep two repos of the same project around. Making a 1.x
release is already confusing enough, having multiple repos will make things
worse.

On Thu, Dec 23, 2021 at 10:35 PM Ralph Goers 
wrote:

> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
> recommended that we can divorce
> the read-only SVN repo from https://github.com/apache/log4j. However, it
> will not be able to keep the same
> name as all Git repos owned by the logging project must start with
> “logging-“.
>
> So this vote is to:
> 1. Delete the apache/logging-log4j1 repo I created last night.
> 2. Divorce the apache/log4j repo from SVN.
> 3. Rename apache/log4j to apache/logging-log4j1.
> 4. Create a branch named “main” from the v1_2_17 tag.
> 5. Make main the default branch in GitHub.
>
> While all votes are welcome Infra needs consensus from the PMC on this
> vote so the result will separate
> binding from non-binding votes.
>
> Ralph
>
> PS - I’ve separated this from the previous vote thread since it was mostly
> discussion. If you want to discuss
> this please prefix the subject with [DISCUSS]

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

Volkan,

Infra has stated their preference is to rename the apache/log4j repo. I only 
went down the path of creating a new repo because I was under the impression 
it would require more infra effort than it apparently does. If it were to stay 
I would 
imagine it would remain read-only. So all the PRs there would be useless, 
although as you point out they may be anyway.

This vote is only about the repo. We will need another discussion and vote 
about 
what the PMC is OK with once the repo is available.

Ralph



> On Dec 24, 2021, at 1:20 AM, Volkan Yazıcı  wrote:
> 
> Gary, I see that you want to stick to the `logging-log4j1` repo Ralph has
> created. What do you propose for the current `log4j` repo? Will they exist
> next to each other? I think that will be a really confusing setup. Can we
> make a pointer from `log4j` to `logging-log4j` in the README and GitHub
> description?
> 
> I agree with stating the goal clearly.
> 
> I don't think we will be able to avoid PRs contributing random stuff to
> Log4j. Once we make a 1.2.18 release, Pandora's box will be open. The only
> thing we can do from then on is to share the goal statement with the
> incoming PRs and simply reject them.
> 
> On Thu, Dec 23, 2021 at 10:50 PM Gary Gregory 
> wrote:
> 
>> -1
>> We just created logging-log4j1 and converted the SVN repo into it, let's
>> stick to that. I even made a commit ;-)
>> I claim it is a good thing to start with a new repo because it creates a
>> tiny bit of friction, for a project that is still End-of-Life after all.
>> Even if it is a bit of friction to bring in old stuff from the old repo,
>> this would provide a kind of effort/value filter.
>> The concurrent consensus I see on the PMC is to fix the one listed CVE on
>> our site plus other fixes in the style of the recent 2.x fixes.
>> Bringing in all of the cruft from the old repo will give the wrong
>> impression that we actually might be merging this or that random fix and
>> feature. Which I claim is not the goal here.
>> 
>> I feel we might need an addendum or a subsequent VOTE with a stated goal or
>> charter for this repo to only provide CVE fixes (see above). Projects
>> usually have a charter, not components I do not think, but I think we
>> should have one here and put it in front and center in the README.md so we
>> can manage expectations for people finding the repo on GitHub.
>> 
>> Gary
>> 
>> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
>> wrote:
>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
>>> recommended that we can divorce
>>> the read-only SVN repo from https://github.com/apache/log4j. However, it
>>> will not be able to keep the same
>>> name as all Git repos owned by the logging project must start with
>>> “logging-“.
>>> 
>>> So this vote is to:
>>> 1. Delete the apache/logging-log4j1 repo I created last night.
>>> 2. Divorce the apache/log4j repo from SVN.
>>> 3. Rename apache/log4j to apache/logging-log4j1.
>>> 4. Create a branch named “main” from the v1_2_17 tag.
>>> 5. Make main the default branch in GitHub.
>>> 
>>> While all votes are welcome Infra needs consensus from the PMC on this
>>> vote so the result will separate
>>> binding from non-binding votes.
>>> 
>>> Ralph
>>> 
>>> PS - I’ve separated this from the previous vote thread since it was
>> mostly
>>> discussion. If you want to discuss
>>> this please prefix the subject with [DISCUSS]
>> 

[DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Volkan Yazıcı]

Gary, I see that you want to stick to the `logging-log4j1` repo Ralph has
created. What do you propose for the current `log4j` repo? Will they exist
next to each other? I think that will be a really confusing setup. Can we
make a pointer from `log4j` to `logging-log4j` in the README and GitHub
description?

I agree with stating the goal clearly.

I don't think we will be able to avoid PRs contributing random stuff to
Log4j. Once we make a 1.2.18 release, Pandora's box will be open. The only
thing we can do from then on is to share the goal statement with the
incoming PRs and simply reject them.

On Thu, Dec 23, 2021 at 10:50 PM Gary Gregory 
wrote:

> -1
> We just created logging-log4j1 and converted the SVN repo into it, let's
> stick to that. I even made a commit ;-)
> I claim it is a good thing to start with a new repo because it creates a
> tiny bit of friction, for a project that is still End-of-Life after all.
> Even if it is a bit of friction to bring in old stuff from the old repo,
> this would provide a kind of effort/value filter.
> The concurrent consensus I see on the PMC is to fix the one listed CVE on
> our site plus other fixes in the style of the recent 2.x fixes.
> Bringing in all of the cruft from the old repo will give the wrong
> impression that we actually might be merging this or that random fix and
> feature. Which I claim is not the goal here.
>
> I feel we might need an addendum or a subsequent VOTE with a stated goal or
> charter for this repo to only provide CVE fixes (see above). Projects
> usually have a charter, not components I do not think, but I think we
> should have one here and put it in front and center in the README.md so we
> can manage expectations for people finding the repo on GitHub.
>
> Gary
>
> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
> wrote:
>
> > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
> > recommended that we can divorce
> > the read-only SVN repo from https://github.com/apache/log4j. However, it
> > will not be able to keep the same
> > name as all Git repos owned by the logging project must start with
> > “logging-“.
> >
> > So this vote is to:
> > 1. Delete the apache/logging-log4j1 repo I created last night.
> > 2. Divorce the apache/log4j repo from SVN.
> > 3. Rename apache/log4j to apache/logging-log4j1.
> > 4. Create a branch named “main” from the v1_2_17 tag.
> > 5. Make main the default branch in GitHub.
> >
> > While all votes are welcome Infra needs consensus from the PMC on this
> > vote so the result will separate
> > binding from non-binding votes.
> >
> > Ralph
> >
> > PS - I’ve separated this from the previous vote thread since it was
> mostly
> > discussion. If you want to discuss
> > this please prefix the subject with [DISCUSS]
>

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Leo Simons]

I see good arguments either way. Most important to me is clarity and a
mandated way forward. This would work well!

If you /don’t/ rename it, ideally it’s PRs should be closed, a “look
elsewhere” README added, and then set to “archived” in GitHub settings. As
extra step could also rename it logging-log4j1-archived.

Best don’t delete it outright: as the source of dozens of other forks that
could confuse otherwise happy forkers.

Cheers,

Leo

On Thu, 23 Dec 2021 at 22:35, Ralph Goers 
wrote:

> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
> recommended that we can divorce
> the read-only SVN repo from https://github.com/apache/log4j. However, it
> will not be able to keep the same
> name as all Git repos owned by the logging project must start with
> “logging-“.
>
> So this vote is to:
> 1. Delete the apache/logging-log4j1 repo I created last night.
> 2. Divorce the apache/log4j repo from SVN.
> 3. Rename apache/log4j to apache/logging-log4j1.
> 4. Create a branch named “main” from the v1_2_17 tag.
> 5. Make main the default branch in GitHub.
>
> While all votes are welcome Infra needs consensus from the PMC on this
> vote so the result will separate
> binding from non-binding votes.
>
> Ralph
>
> PS - I’ve separated this from the previous vote thread since it was mostly
> discussion. If you want to discuss
> this please prefix the subject with [DISCUSS]