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 work
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
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
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 i
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 mentio
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,
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
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
>
>
>
> ###
+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 key
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
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
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 differenc
> 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
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 p
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 != consens
>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
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, the
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/loggin
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
>
> Bi
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
>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
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 tha
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
>> t
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
> 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
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
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:/
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 be
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
Sicke
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 Grobmei
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.
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 sim
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
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 commun
"we are doing a CVE+" -> "we might do a CVE+"
On Fri, Dec 24, 2021, 09:19 Gary Gregory wrote:
> 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
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
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
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 b
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`?
>
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-lo
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, forb
My reasoning behind my +1 vote is that it is good to have the log4j1
repository on git, aligned with other repositories and easily available to
the public.
As a starter, the repository should clearly mention its EOL and NOT provide
any interactivity through issues and pull requests.
--
Sent from
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
`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,
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
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 l
+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
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
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
desc
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
50 matches
Mail list logo
