Re: [log4cxx] next_stable and other fixes

Once the branches diverge, git cherry-pick is the better merge process. On Tue, Jan 4, 2022 at 11:06 AM Robert Middleton wrote: > Just as a note to all, what I've been doing with next_stable is to > periodically merge master back in once I make fixes on master(assuming > that those fixes are com

[log4cxx] next_stable and other fixes

Just as a note to all, what I've been doing with next_stable is to periodically merge master back in once I make fixes on master(assuming that those fixes are common to both). Unfortunately with the multithreaded speed fix this has resulted in a moderately sized merge conflict. I think I've fixed

Re: [VOTE] Future of Log4j 1.x

+1 for Option 1 On 12/29/2021 2:33 PM, Christian Grobmeier wrote: Hello, as discussed in another thread, this is a vote about the future of log4j 1. This vote stays open for the usual 72h. Options are explained below. You can vote for: [ ] +1, Option 1 [ ] +1, Option 2 [ ] +/- 0, absta

[VOTE] Release Log4j Scala API 12.1-rc1

This is a vote to release Log4j Scala API 12.1. This was previously being released as 13.0, though we’re going back down to a minor update. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain o

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 5

Releasing this. On Mon, Dec 27, 2021 at 6:40 PM Matt Sicker wrote: > > This is a vote by lazy approval to release Logging Parent POM version 5. An > action with lazy approval is implicitly allowed unless a -1 vote is received, > at which time, depending on the type of action, either lazy majori

Re: Master branch

> On Jan 3, 2022, at 1:47 PM, Volkan Yazıcı wrote: >> > > Sorry, I think I have been a victim of my own incorrect wording. I rather > wanted to suggest "placing all tests _exposed as test JARs_ to their own > modules". I think we both agree on this. Please, correct me if I am wrong. There is

Re: [VOTE] Future of Log4j 1.x

+1 Option 1 -ck > On Dec 29, 2021, at 14:33, Christian Grobmeier wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1,

Re: Master branch

On Mon, Jan 3, 2022 at 5:28 PM Ralph Goers wrote: > > > > On Jan 3, 2022, at 5:30 AM, Volkan Yazıcı wrote: > > > > Fantastic work Ralph! Please see my comments below: > > > > On Tue, Dec 28, 2021 at 9:39 AM Ralph Goers > > wrote: > >> Most of the components that were generating test jars have b

Re: [VOTE] Future of Log4j 1.x

+1, Option 1 On Wed, Dec 29, 2021, at 20:33, Christian Grobmeier wrote: > Hello, > > as discussed in another thread, this is a vote about the future of > log4j 1. This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option

Re: [DISCUSS][VOTE] Future of Log4j 1.x

Hi Leo, good new year to you! On Sun, Jan 2, 2022, at 07:12, Leo Simons wrote: > Hey, > > Happy new year everyone! > > On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers > wrote: > >> Leo seemed interested at first but didn’t weigh in on the discussion >> thread. > > > I'm here. I did mention in a co

Re: [VOTE] CVE creation process

+1 for going with lazy approval CVE process. -- Matt Sicker > On Jan 3, 2022, at 05:59, Volkan Yazıcı wrote: > > Hello, > > As discussed earlier[1], this is a vote to introduce the process that > enforces CVE submissions and their content should be first subject to > voting using the (private)

Re: LOG4J2-3259 Limit max recursion depth when interpolating strings

Thanks for raising this discussion Volkan. I have a few points I'd like to make sure have been considered: The intent is that the limit should be set sufficiently high that no one is realistically going to want to exceed it. I'm happy to make it adjustable if you think people will need it, I just

Re: [VOTE] CVE creation process

+1, as this only affects the creation of cves but does not block the fixing going on immediately. I think we do not require majority though, just waiting if someone objects is fine for me On Mon, Jan 3, 2022, at 12:59, Volkan Yazıcı wrote: > Hello, > > As discussed earlier[1], this is a vote to

Re: LOG4J2-3259 Limit max recursion depth when interpolating strings

I would think an option to silence would be ok if off by default. I wouldn't want it, but some may. As for the return, empty would be better than partial as that may open bad values - not sure that could be abused, but if an attacker figured out the limit, they may be able to craft something bad t

Re: [DISCUSS][VOTE] CVE creation process

Lazy approval is the technical term for the voting style you’re describing. Lazy consensus is how committers and PMC members are voted on. Snippet: * Lazy consensus requires 3 binding +1 votes and no binding vetoes. * A lazy majority vote requires 3 binding +1 votes and more binding +1 votes tha

Re: Master branch

There’s already a ticket for JUnit 5 I filed a while ago. — Matt Sicker > On Jan 3, 2022, at 10:28, Ralph Goers wrote: > >  > >> On Jan 3, 2022, at 5:30 AM, Volkan Yazıcı wrote: >> >> Fantastic work Ralph! Please see my comments below: >> >>> On Tue, Dec 28, 2021 at 9:39 AM Ralph Goers >>

Re: LOG4J2-3259 Limit max recursion depth when interpolating strings

I think Ralph is right: there should (could) be a limit on how often the user is informed but the user does need to be informed. On Mon, Jan 3, 2022 at 8:32 AM Ralph Goers wrote: > I am in favor of limiting the recursion depth to a configurable with a > default number. > I fully expect virtually

Re: LOG4J2-3259 Limit max recursion depth when interpolating strings

I am in favor of limiting the recursion depth to a configurable with a default number. I fully expect virtually all normal usage would fall within the limits of whatever we would pick as the default. But should that limit be hit we can’t just return crap silently. It almost certainly means s

Re: Master branch

> On Jan 3, 2022, at 5:30 AM, Volkan Yazıcı wrote: > > Fantastic work Ralph! Please see my comments below: > > On Tue, Dec 28, 2021 at 9:39 AM Ralph Goers > wrote: >> Most of the components that were generating test jars have been split > into two modules - the main component, >> which only

Re: [VOTE] CVE creation process

+-0 I have no strong opinion. I do believe that an informal consensus about our best practice should be all we need. It should suffice when two pmc members acknowledge both fix and official communication. My perception is that we already do our best. Beyond that, it will always be a walk on the ed

[DISCUSS][VOTE] CVE creation process

While you may think they are just investigating the vulnerability there really is a lot more that goes on behind the scenes. I know the second or third CVE we addressed took several days for me to be able to confirm it was actually a vulnerability. I was quite surprised that the DNS system does

RE: [VOTE] CVE creation process

> -Original Message- > From: Xeno Amess > Sent: Monday, January 3, 2022 10:40 AM > > +0 > > I just worried several things. > > 1. Will it make the cve's fix come out more slowly? > A vote means waiting for 72 hours usually. > > 2. Do all PMC who enter the vote always have enough ability

[DISCUSS\[VOTE] CVE creation process

These are two really good questions! The 72 hours is recommended due to people being spread around the world and people being unavailable due to pressing $dayjob or family items, weekends, etc. But in an emergency the voting period can be compressed. This PMC has done a remarkably good job of

[DISCUSS][VOTE] CVE creation process

I would have recommended doing this vote by lazy consensus - i.e. you only need to vote if you object, since we have previously discussed this and no one seemed to object. Ralph > On Jan 3, 2022, at 4:59 AM, Volkan Yazıcı wrote: > > Hello, > > As discussed earlier[1], this is a vote to intro

Re: [VOTE] CVE creation process

It is already slow enough... I submitted a vulnerability which I think at least can be 7 points, to an apache project (not this one) the day before yesterday. And they have not finished the investigation yet...two days already... And considering this is in vocation, it is normal to assume the ac

Re: [VOTE] CVE creation process

+1 Ralph > On Jan 3, 2022, at 4:59 AM, Volkan Yazıcı wrote: > > Hello, > > As discussed earlier[1], this is a vote to introduce the process that > enforces CVE submissions and their content should be first subject to > voting using the (private) `secur...@logging.apache.org` mailing list. > >

Re: [VOTE] CVE creation process

+0 I just worried several things. 1. Will it make the cve's fix come out more slowly? A vote means waiting for 72 hours usually. 2. Do all PMC who enter the vote always have enough ability and knowledge for notifying how severe a vulnerability? Some vulnerabilities are, seems small problem, noth

Re: [VOTE] CVE creation process

+1 -ck > On Jan 3, 2022, at 6:59 AM, Volkan Yazıcı wrote: > > Hello, > > As discussed earlier[1], this is a vote to introduce the process that > enforces CVE submissions and their content should be first subject to > voting using the (private) `secur...@logging.apache.org` mailing list. > > [

Re: [VOTE] CVE creation process

[X] +1, accept the process Gary On Mon, Jan 3, 2022 at 6:59 AM Volkan Yazıcı wrote: > Hello, > > As discussed earlier[1], this is a vote to introduce the process that > enforces CVE submissions and their content should be first subject to > voting using the (private) `secur...@logging.apache.or

Re: LOG4J2-3259 Limit max recursion depth when interpolating strings

I was thinking about this the other day in the following terms: How would a user or dev know that something went wrong? Let's say I load a config and I see the logging is incorrect in some way. Under the covers, it's because recursion hit a limit. So how can a user or dev know they need to enable

LOG4J2-3259 Limit max recursion depth when interpolating strings

There is a PR for this issue, shall we bring this to a conclusion? I am in favor of this PR if the following changes were implemented: - limit is read from a property - limit is documented - stay quiet (i.e., not StatusLogger exception logging) i

Re: Master branch

Fantastic work Ralph! Please see my comments below: On Tue, Dec 28, 2021 at 9:39 AM Ralph Goers wrote: > Most of the components that were generating test jars have been split into two modules - the main component, > which only builds the jar, and a -test component that builds a -test jar and then

[VOTE] CVE creation process

Hello, As discussed earlier[1], this is a vote to introduce the process that enforces CVE submissions and their content should be first subject to voting using the (private) `secur...@logging.apache.org` mailing list. [] +1, accept the process [] -1, object to the process because... The vote wil