Re: [DISCUSS] Starting social media accounts for subprojects

[Davyd McColl]

+1 for accounts per project

-d


On December 31, 2021 01:02:08 Remko Popma  wrote:


I also like this idea and agree with separate accounts for each component.

On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory  wrote:


Great idea. I would suggest one account for the each component. I'm not
sure anyone but the PMC would care about a logging services account.

Gary

On Thu, Dec 30, 2021, 17:40 Matt Sicker  wrote:

> We recently had an idea discussed on a video call about potentially
> starting some Twitter et al. accounts for announcing releases, release
> candidates, and larger upcoming changes to subprojects (e.g., changing
the
> minimum major version of the underlying programming language or build
> tooling, major version releases like 2.x -> 3.x, etc). While the dev list
> remains our official place to discuss development, it would be immensely
> useful for communicating with our wider user base about changes that may
be
> more relevant to them than to active developers and contributors.
>
> What do you all think? If we do make accounts, would it make sense to
> divide them into accounts like @log4j, @log4net, @log4cxx, etc., or
should
> they be created like a common account for the whole Logging PMC? And
which
> social media sites would be best to use here? Twitter is an obvious
choice,
> but there could also be other tech-heavy social media sites that would
also
> benefit.
> --
> Matt Sicker
>
>

RE: Forwarding email per Matt Sicker suggestion

[Dick Brooks]

Remko and Ralph,

 

   I’m currently providing materials to NIST on updates to the 
draft C-SCRM standard SP 800-161 R2 Appendix F 

  to meet Cybersecurity Executive Order 14028 

 . The final version of SP 800-161 is expected to be published in early 
February 2022 with implementations starting in late Summer 2022. One of the 
requirements of EO 14028 is to provide the US Govt with NTIA compliant SBOM’s 
and vulnerability reports. 

   During discussions within the NTIA SBOM initiative the topic of 
vulnerability reporting was discussed, but was considered out of scope for the 
SBOM charter. The Vulnerability Exchange (VEX) initiative was discussed as a 
possible vulnerability reporting solution and a VEX profile was added to the 
OASIS CSAF initiative. The problem with VEX is that it reports vulnerabilities 
at the product level, i.e. Log4j-core but there is no direct correlation to 
SBOM’s that contain this component. 

That’s when I began to work on an open-source SBOM Vulnerability Disclosure 
Report (VDR) XML schema that lists CVE’s at the component level of a product 
SBOM. This will enable government entities to automate the processing of 
Vulnerability Disclosure Reports based on SBOM component level vulnerabilities 
in order to meet EO 14028 requirements. 

 

The open source SBOM VDR XML schema and an example VDR report are available 
online:

https://www.einpresswire.com/article/559309448/updated-open-source-sbom-vulnerability-disclosure-report-format-for-rapid-risk-assessment-and-response?ref=email
 

 
=Kg7BjRgTJ3VzyWI6_source=NewsletterPR_medium=email_campaign=All+Featured+Press+Releases_content=article
 

 

NOTE: There is a possibility that NIST will choose another vulnerability 
reporting format in the final release of SP 800-161 in 2/2022, however, the 
SBOM VDR is currently the only open source option available that reports CVE’s 
at the SBOM component level, to my knowledge.

 

Thanks,

 

Dick Brooks



  Never trust software, always 
verify and report! ™

  
http://www.reliableenergyanalytics.com

Email:   
d...@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Remko Popma  
Sent: Thursday, December 30, 2021 5:46 PM
To: Apache Logging Developers List ; Dick Brooks 

Subject: Re: Forwarding email per Matt Sicker suggestion

 

 

On Tue, Dec 21, 2021 at 2:41 AM Ralph Goers mailto:ralph.go...@dslextreme.com> > wrote:

Thanks Dick,

I am totally unfamiliar with this. Is there somewhere to read about what this 
is all about?

Ralph

 

Resending, including Dick in the recipients.

 


> On Dec 20, 2021, at 7:18 AM, Dick Brooks   > wrote:
> 
> Hello,
>  
> This sort of suggestion would be better sent to our development mailing list 
> (dev@logging.apache.org   
>  >). I’ll note 
> that we use Apache Maven for our build system, and a quick search shows that 
>  > might be a useful 
> plugin to propose for generating the SBOM as part of our standard release 
> process. I do think it’s a good idea, but this topic should be discussed in 
> our public list and not on the private list.
> --
> Matt Sicker 
> 
> 
> On Dec 19, 2021, at 12:48, Dick Brooks    
>   >> wrote:
>  
> I’ve created an SPDX SBOM for Log4j V 2.17.0-core along with a companion 
> baseline vulnerability disclosure report (VDR), based on NIST NVD search 
> results:
> https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase 
> 
>  
> Please read the README.md first to understand the limitations of this info.
>  
> I encourage the Log4j team to consider updating the FixStatus and 
> AnalysisFindings elements for each reported CVE. I’m happy to assist in this 
> effort.
>  
> Thanks,
>  
> Dick Brooks
> 
> Never trust software, always verify and report! 
>  ™
> http://www.reliableenergyanalytics.com 
> 
> Email: d...@reliableenergyanalytics.com 
>   
> 

Re: [DISCUSS] Starting social media accounts for subprojects

[Remko Popma]

I also like this idea and agree with separate accounts for each component.

On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory  wrote:

> Great idea. I would suggest one account for the each component. I'm not
> sure anyone but the PMC would care about a logging services account.
>
> Gary
>
> On Thu, Dec 30, 2021, 17:40 Matt Sicker  wrote:
>
> > We recently had an idea discussed on a video call about potentially
> > starting some Twitter et al. accounts for announcing releases, release
> > candidates, and larger upcoming changes to subprojects (e.g., changing
> the
> > minimum major version of the underlying programming language or build
> > tooling, major version releases like 2.x -> 3.x, etc). While the dev list
> > remains our official place to discuss development, it would be immensely
> > useful for communicating with our wider user base about changes that may
> be
> > more relevant to them than to active developers and contributors.
> >
> > What do you all think? If we do make accounts, would it make sense to
> > divide them into accounts like @log4j, @log4net, @log4cxx, etc., or
> should
> > they be created like a common account for the whole Logging PMC? And
> which
> > social media sites would be best to use here? Twitter is an obvious
> choice,
> > but there could also be other tech-heavy social media sites that would
> also
> > benefit.
> > --
> > Matt Sicker
> >
> >
>

Re: [DISCUSS] Starting social media accounts for subprojects

[Gary Gregory]

Great idea. I would suggest one account for the each component. I'm not
sure anyone but the PMC would care about a logging services account.

Gary

On Thu, Dec 30, 2021, 17:40 Matt Sicker  wrote:

> We recently had an idea discussed on a video call about potentially
> starting some Twitter et al. accounts for announcing releases, release
> candidates, and larger upcoming changes to subprojects (e.g., changing the
> minimum major version of the underlying programming language or build
> tooling, major version releases like 2.x -> 3.x, etc). While the dev list
> remains our official place to discuss development, it would be immensely
> useful for communicating with our wider user base about changes that may be
> more relevant to them than to active developers and contributors.
>
> What do you all think? If we do make accounts, would it make sense to
> divide them into accounts like @log4j, @log4net, @log4cxx, etc., or should
> they be created like a common account for the whole Logging PMC? And which
> social media sites would be best to use here? Twitter is an obvious choice,
> but there could also be other tech-heavy social media sites that would also
> benefit.
> --
> Matt Sicker
>
>

Re: Forwarding email per Matt Sicker suggestion

[Remko Popma]

On Tue, Dec 21, 2021 at 2:41 AM Ralph Goers 
wrote:

> Thanks Dick,
>
> I am totally unfamiliar with this. Is there somewhere to read about what
> this is all about?
>
> Ralph
>

Resending, including Dick in the recipients.


>
> > On Dec 20, 2021, at 7:18 AM, Dick Brooks <
> d...@reliableenergyanalytics.com> wrote:
> >
> > Hello,
> >
> > This sort of suggestion would be better sent to our development mailing
> list (dev@logging.apache.org ). I’ll note
> that we use Apache Maven for our build system, and a quick search shows
> that  https://github.com/CycloneDX/cyclonedx-maven-plugin>> might be a useful
> plugin to propose for generating the SBOM as part of our standard release
> process. I do think it’s a good idea, but this topic should be discussed in
> our public list and not on the private list.
> > --
> > Matt Sicker
> >
> >
> > On Dec 19, 2021, at 12:48, Dick Brooks  > wrote:
> >
> > I’ve created an SPDX SBOM for Log4j V 2.17.0-core along with a companion
> baseline vulnerability disclosure report (VDR), based on NIST NVD search
> results:
> > https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase <
> https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase>
> >
> > Please read the README.md first to understand the limitations of this
> info.
> >
> > I encourage the Log4j team to consider updating the FixStatus and
> AnalysisFindings elements for each reported CVE. I’m happy to assist in
> this effort.
> >
> > Thanks,
> >
> > Dick Brooks
> > 
> > Never trust software, always verify and report! <
> https://reliableenergyanalytics.com/products> ™
> > http://www.reliableenergyanalytics.com <
> http://www.reliableenergyanalytics.com/>
> > Email: d...@reliableenergyanalytics.com  d...@reliableenergyanalytics.com>
> > Tel: +1 978-696-1788
> >
> >
> >
> > Thanks,
> >
> > Dick Brooks
> >
> > Never trust software, always verify and report! <
> https://reliableenergyanalytics.com/products> ™
> > http://www.reliableenergyanalytics.com <
> http://www.reliableenergyanalytics.com/>
> > Email: d...@reliableenergyanalytics.com  d...@reliableenergyanalytics.com>
> > Tel: +1 978-696-1788
>
>

[DISCUSS] Starting social media accounts for subprojects

[Matt Sicker]

We recently had an idea discussed on a video call about potentially starting 
some Twitter et al. accounts for announcing releases, release candidates, and 
larger upcoming changes to subprojects (e.g., changing the minimum major 
version of the underlying programming language or build tooling, major version 
releases like 2.x -> 3.x, etc). While the dev list remains our official place 
to discuss development, it would be immensely useful for communicating with our 
wider user base about changes that may be more relevant to them than to active 
developers and contributors.

What do you all think? If we do make accounts, would it make sense to divide 
them into accounts like @log4j, @log4net, @log4cxx, etc., or should they be 
created like a common account for the whole Logging PMC? And which social media 
sites would be best to use here? Twitter is an obvious choice, but there could 
also be other tech-heavy social media sites that would also benefit.
--
Matt Sicker

Re: CVE creation process

[Gary Gregory]

I like the idea of voting on whether or not we want to CVE a fix because I
hope it will make us focus on how to message the issue as clearly as
possible in addition to having more eyes looking at similar possible issues.

Gary

On Thu, Dec 30, 2021 at 4:02 AM Volkan Yazıcı  wrote:

> Hello,
>
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
>
> I am told by secur...@apache.org that what is CVE-worthy is up to the
> PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
>
> Kind regards.
>

Re: CVE creation process

[Ralph Goers]

Thanks for putting it into practical terms.  I wish it was that black and white 
though.
I don’t really know how much JNDI is used any more. When I learned Java JNDI 
was 
the standard way to access LDAP.  So I can easily imagine that there are 
configurations 
out there that are retrieving some passwords from it to access something from 
the 
logging configuration completely unaware that they may already have be 
compromised.

But how many are there that are doing that? Less than 1%?  What is worse, is 
that the 
fix will no longer allow them to access LDAP that way so many of those who this 
fix is 
meant to protect won’t upgrade.

Still, I have to agree that it wasn’t safe to allow users to access LDAP (as 
well as other 
protocols) this way and users needed to be informed. 

Ralph



> On Dec 30, 2021, at 10:01 AM, Julius Davies  wrote:
> 
> Hello,
> 
> Long time lurker here.
> 
> There are probably tens of thousands of CVEs in the NVD that are
> theoretically exploitable, but in practice will never be exploited. I
> wouldn't take things people say on twitter too seriously when it comes to
> determining CVE-worthiness.
> 
> I mainly think of the CVE system as a way to boost and amplify
> communication around patch releases, and to help convey to the public the
> importance of taking a given update.
> 
> If the log4j team agreed that it's not safe for consumers of Log4J to
> remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
> thinks.
> 
> 
> yours,
> 
> Julius
> 
> 
> 
> On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers 
> wrote:
> 
>> I have no objection to this but it obviously has to be done on the private
>> list.
>> 
>> I happen to disagree with your assessment of 44832. As far as I am
>> concerned any
>> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
>> just how
>> bad it is. Any design that lets you download code from a random web server
>> that then
>> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
>> works.
>> 
>> Ralph
>> 
>>> On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı  wrote:
>>> 
>>> Hello,
>>> 
>>> The recent CVE-2021-44832 has been subject to quite some debate whether
>> it
>>> was CVE-worthy or not. I think that one had far fetched assumptions and
>>> could very well be addressed in a patch release, just like we did, but
>>> without a CVE associated with it. The created CVE caused yet another wave
>>> of FUD surrounding the project. I can imagine millions of deployments all
>>> around the world were marked as flagged by monitoring tools and people
>>> rushed to upgrade in panic, most likely, for no reason. I put aside the
>>> damage CVEs cause on the reputation of the project.
>>> 
>>> I am told by secur...@apache.org that what is CVE-worthy is up to the
>> PMC. *I
>>> propose creating a VOTE thread for the CVE creation from now on.* I would
>>> appreciate it if others can share their thoughts on this. If the overall
>>> reception is positive, I will send a VOTE email to make this official.
>>> 
>>> Kind regards.
>> 
>> 

Re: CVE creation process

[Julius Davies]

p.s.  The fact CVE-2021-44832 was scored as CVSS v3 Base 6.6 = Medium means
probably most companies will not urgently take this patch.  I've seen
policies in practice (at companies) that consider 7.0 and up ("HIGH") as
patch-in-7-days, and 9.0 and up ("CRITICAL") as patch-in-3-days, and things
like this.  So the fact you scored it as 6.6 Medium was great for helping
consumers understand the fact this one was not as urgent as some of the
others.

I really wouldn't worry whether the CVE was worthy or not - it's better to
issue a CVE that wasn't needed compared to the inverse!



On Thu, Dec 30, 2021 at 9:01 AM Julius Davies 
wrote:

> Hello,
>
> Long time lurker here.
>
> There are probably tens of thousands of CVEs in the NVD that are
> theoretically exploitable, but in practice will never be exploited. I
> wouldn't take things people say on twitter too seriously when it comes to
> determining CVE-worthiness.
>
> I mainly think of the CVE system as a way to boost and amplify
> communication around patch releases, and to help convey to the public the
> importance of taking a given update.
>
> If the log4j team agreed that it's not safe for consumers of Log4J to
> remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
> thinks.
>
>
> yours,
>
> Julius
>
>
>
> On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers 
> wrote:
>
>> I have no objection to this but it obviously has to be done on the
>> private list.
>>
>> I happen to disagree with your assessment of 44832. As far as I am
>> concerned any
>> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
>> just how
>> bad it is. Any design that lets you download code from a random web
>> server that then
>> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
>> works.
>>
>> Ralph
>>
>> > On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı  wrote:
>> >
>> > Hello,
>> >
>> > The recent CVE-2021-44832 has been subject to quite some debate whether
>> it
>> > was CVE-worthy or not. I think that one had far fetched assumptions and
>> > could very well be addressed in a patch release, just like we did, but
>> > without a CVE associated with it. The created CVE caused yet another
>> wave
>> > of FUD surrounding the project. I can imagine millions of deployments
>> all
>> > around the world were marked as flagged by monitoring tools and people
>> > rushed to upgrade in panic, most likely, for no reason. I put aside the
>> > damage CVEs cause on the reputation of the project.
>> >
>> > I am told by secur...@apache.org that what is CVE-worthy is up to the
>> PMC. *I
>> > propose creating a VOTE thread for the CVE creation from now on.* I
>> would
>> > appreciate it if others can share their thoughts on this. If the overall
>> > reception is positive, I will send a VOTE email to make this official.
>> >
>> > Kind regards.
>>
>>

Re: CVE creation process

[Julius Davies]

Hello,

Long time lurker here.

There are probably tens of thousands of CVEs in the NVD that are
theoretically exploitable, but in practice will never be exploited. I
wouldn't take things people say on twitter too seriously when it comes to
determining CVE-worthiness.

I mainly think of the CVE system as a way to boost and amplify
communication around patch releases, and to help convey to the public the
importance of taking a given update.

If the log4j team agreed that it's not safe for consumers of Log4J to
remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
thinks.


yours,

Julius



On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers 
wrote:

> I have no objection to this but it obviously has to be done on the private
> list.
>
> I happen to disagree with your assessment of 44832. As far as I am
> concerned any
> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
> just how
> bad it is. Any design that lets you download code from a random web server
> that then
> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
> works.
>
> Ralph
>
> > On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı  wrote:
> >
> > Hello,
> >
> > The recent CVE-2021-44832 has been subject to quite some debate whether
> it
> > was CVE-worthy or not. I think that one had far fetched assumptions and
> > could very well be addressed in a patch release, just like we did, but
> > without a CVE associated with it. The created CVE caused yet another wave
> > of FUD surrounding the project. I can imagine millions of deployments all
> > around the world were marked as flagged by monitoring tools and people
> > rushed to upgrade in panic, most likely, for no reason. I put aside the
> > damage CVEs cause on the reputation of the project.
> >
> > I am told by secur...@apache.org that what is CVE-worthy is up to the
> PMC. *I
> > propose creating a VOTE thread for the CVE creation from now on.* I would
> > appreciate it if others can share their thoughts on this. If the overall
> > reception is positive, I will send a VOTE email to make this official.
> >
> > Kind regards.
>
>

Re: CVE creation process

[Ralph Goers]

I have no objection to this but it obviously has to be done on the private list.

I happen to disagree with your assessment of 44832. As far as I am concerned 
any 
uncontrolled use of JNDI requires a CVE. People don’t seem to understand just 
how 
bad it is. Any design that lets you download code from a random web server that 
then 
runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP works.

Ralph

> On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
> 
> I am told by secur...@apache.org that what is CVE-worthy is up to the PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
> 
> Kind regards.

Re: CVE creation process

[Matt Sicker]

I think this is a good idea. I clarified the CVE details yesterday to note the 
specific JNDI and LDAP issue, but the FUD is already out there.

—
Matt Sicker

> On Dec 30, 2021, at 03:02, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
> 
> I am told by secur...@apache.org that what is CVE-worthy is up to the PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
> 
> Kind regards.

Re: rat:check at verify

[Gary Gregory]

+1 :-)

Gary

On Thu, Dec 30, 2021, 08:40 Carter Kozak  wrote:

> Thank you!
>
> -ck
>
> > On Dec 30, 2021, at 02:27, Volkan Yazıcı  wrote:
> >
> > Pushed to both `release-2.x` and `master`.
> >
> >> On Wed, Dec 29, 2021 at 10:25 AM Volkan Yazıcı  wrote:
> >>
> >> I suggest hooking apache-rat:check up to the verify stage in Maven. This
> >> will make CI run that goal too. Objections?
> >>
>
>

Re: rat:check at verify

[Carter Kozak]

Thank you!

-ck

> On Dec 30, 2021, at 02:27, Volkan Yazıcı  wrote:
> 
> Pushed to both `release-2.x` and `master`.
> 
>> On Wed, Dec 29, 2021 at 10:25 AM Volkan Yazıcı  wrote:
>> 
>> I suggest hooking apache-rat:check up to the verify stage in Maven. This
>> will make CI run that goal too. Objections?
>> 

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

[Vladimir Sitnikov]

Christian>vote in this thread, which is, btw not meant for discussion but
for voting.

We are on a [DISCUSS] thread (check the subject).

Ralph "created" [DISCUSS] thread by hitting "reply" and changing the
subject.
"reply" keeps message-id, so it might look like a single thread.

See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j
1.x"
at https://lists.apache.org/list.html?dev@logging.apache.org

Vladimir

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

[Christian Grobmeier]

If there is long term commitment apart from these urgent fixes we can run 
another vote.

You cannot guarantee you are alive by February, nobody can give such guarantees.

The logging pmc is not here to accept all patches as they come in but to make 
decisions best to the project (among other duties).

Once there is a mandate and consent among pmc we most likely try to review and 
comment on the prs coming in. No guarantees though your pr will be accepted as 
it is.

That said, we continue to vote in New committers and pmc members as we always 
have. Prerequisites to become logging committer is long term interest in 
logging and understanding the ASF way. Also, I daresay, many people here like 
to add new people when they are adding positive attitude (versus toxic 
behavior).

I hope all your questions are clarified now and we can continue to discuss (see 
Ralph's message) on slack and vote in this thread, which is, btw not meant for 
discussion but for voting.

--
The Apache Software Foundation
V.P., Data Privacy

On Wed, Dec 29, 2021, at 21:41, Vladimir Sitnikov wrote:
>>Log4j is owned by the Logging Services PMC. You cannot incubate it without
> this PMC’s approval.
>
> Exactly. As far as I understand, Logging pmc should accept patches and
> release fixes or they should approve reincubating.
> Of course, you can try rejecting patches and disapprove reincubation,
> however, that won't hold water.
>
> Unfortunately, I have not seen the response from the logging pmc regarding
> approve/disapprove re-incubating. There's a pending question to Ron still.
>
> I do not consider forks outside of the ASF.
>
>>But I notice the one topic you did not respond to was the lack of
> interested people other than yourself. Why is that?
>
> I find the question irrelevant, and I find it has nothing to do with
> accepting patches and releasing 1.2
> I belive there were even people on incubator thread, so it is strange why
> do you demand that I provide you with a list of rock-star 1.x maintainers.
>
> 1) I can't guarantee I will be alive in February. Can you guarantee all the
> logging pmc members will be alive then? I doubt so. So I find that
> questions like "how can we be sure you will send patches" too intimate.
>
> 2) I have already filed a patch for buildscripts. Whould you review it and
> merge?
>
> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
> 1.2. What do you do then? Would you add all of them to the logging pmc?
> I don't really see the point why do you ask, and at the same time I can't
> guarantee the people I gather will be alive tomorrow. I can't guarantee
> they will always have interest in 1.2
>
> Vladimir

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

[Christian Grobmeier]

Makes sense. I will close thus vote not earlier than Jan 5, if there is no 
further objections. Thanks for  your input Tim

--
The Apache Software Foundation
V.P., Data Privacy

On Thu, Dec 30, 2021, at 01:56, Tim Perry wrote:
> I propose that this vote should stay open longer than 72 hours given 
> that we are coming up on New Years and many people who would wish to 
> weigh in might be on vacation right now. 
>
> Tim
>
>> On Dec 29, 2021, at 2:29 PM, Matt Sicker  wrote:
>> 
>> Consistent contributors are frequently invited to be committers and later 
>> PMC members. Having at least three people maintaining anything is an Apache 
>> standard for maintaining vendor neutrality, ensuring a minimum number of 
>> people can verify release candidates to address security issues or any other 
>> releases.
>> 
>> —
>> Matt Sicker
>> 
>>> On Dec 29, 2021, at 14:41, Vladimir Sitnikov  
>>> wrote:
>>> 
>>> 
 
 Log4j is owned by the Logging Services PMC. You cannot incubate it without
>>> this PMC’s approval.
>>> 
>>> Exactly. As far as I understand, Logging pmc should accept patches and
>>> release fixes or they should approve reincubating.
>>> Of course, you can try rejecting patches and disapprove reincubation,
>>> however, that won't hold water.
>>> 
>>> Unfortunately, I have not seen the response from the logging pmc regarding
>>> approve/disapprove re-incubating. There's a pending question to Ron still.
>>> 
>>> I do not consider forks outside of the ASF.
>>> 
 But I notice the one topic you did not respond to was the lack of
>>> interested people other than yourself. Why is that?
>>> 
>>> I find the question irrelevant, and I find it has nothing to do with
>>> accepting patches and releasing 1.2
>>> I belive there were even people on incubator thread, so it is strange why
>>> do you demand that I provide you with a list of rock-star 1.x maintainers.
>>> 
>>> 1) I can't guarantee I will be alive in February. Can you guarantee all the
>>> logging pmc members will be alive then? I doubt so. So I find that
>>> questions like "how can we be sure you will send patches" too intimate.
>>> 
>>> 2) I have already filed a patch for buildscripts. Whould you review it and
>>> merge?
>>> 
>>> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
>>> 1.2. What do you do then? Would you add all of them to the logging pmc?
>>> I don't really see the point why do you ask, and at the same time I can't
>>> guarantee the people I gather will be alive tomorrow. I can't guarantee
>>> they will always have interest in 1.2
>>> 
>>> Vladimir

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

[Dominik Psenner]

+1, Option 1

People should migrate to log4j2.

On Thu, 30 Dec 2021 at 01:56, Tim Perry  wrote:

> I propose that this vote should stay open longer than 72 hours given that
> we are coming up on New Years and many people who would wish to weigh in
> might be on vacation right now.
>
> Tim
>
> > On Dec 29, 2021, at 2:29 PM, Matt Sicker  wrote:
> >
> > Consistent contributors are frequently invited to be committers and
> later PMC members. Having at least three people maintaining anything is an
> Apache standard for maintaining vendor neutrality, ensuring a minimum
> number of people can verify release candidates to address security issues
> or any other releases.
> >
> > —
> > Matt Sicker
> >
> >> On Dec 29, 2021, at 14:41, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> >>
> >> 
> >>>
> >>> Log4j is owned by the Logging Services PMC. You cannot incubate it
> without
> >> this PMC’s approval.
> >>
> >> Exactly. As far as I understand, Logging pmc should accept patches and
> >> release fixes or they should approve reincubating.
> >> Of course, you can try rejecting patches and disapprove reincubation,
> >> however, that won't hold water.
> >>
> >> Unfortunately, I have not seen the response from the logging pmc
> regarding
> >> approve/disapprove re-incubating. There's a pending question to Ron
> still.
> >>
> >> I do not consider forks outside of the ASF.
> >>
> >>> But I notice the one topic you did not respond to was the lack of
> >> interested people other than yourself. Why is that?
> >>
> >> I find the question irrelevant, and I find it has nothing to do with
> >> accepting patches and releasing 1.2
> >> I belive there were even people on incubator thread, so it is strange
> why
> >> do you demand that I provide you with a list of rock-star 1.x
> maintainers.
> >>
> >> 1) I can't guarantee I will be alive in February. Can you guarantee all
> the
> >> logging pmc members will be alive then? I doubt so. So I find that
> >> questions like "how can we be sure you will send patches" too intimate.
> >>
> >> 2) I have already filed a patch for buildscripts. Whould you review it
> and
> >> merge?
> >>
> >> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to
> support
> >> 1.2. What do you do then? Would you add all of them to the logging pmc?
> >> I don't really see the point why do you ask, and at the same time I
> can't
> >> guarantee the people I gather will be alive tomorrow. I can't guarantee
> >> they will always have interest in 1.2
> >>
> >> Vladimir
>


-- 
Dominik Psenner

CVE creation process

[Volkan Yazıcı]

Hello,

The recent CVE-2021-44832 has been subject to quite some debate whether it
was CVE-worthy or not. I think that one had far fetched assumptions and
could very well be addressed in a patch release, just like we did, but
without a CVE associated with it. The created CVE caused yet another wave
of FUD surrounding the project. I can imagine millions of deployments all
around the world were marked as flagged by monitoring tools and people
rushed to upgrade in panic, most likely, for no reason. I put aside the
damage CVEs cause on the reputation of the project.

I am told by secur...@apache.org that what is CVE-worthy is up to the PMC. *I
propose creating a VOTE thread for the CVE creation from now on.* I would
appreciate it if others can share their thoughts on this. If the overall
reception is positive, I will send a VOTE email to make this official.

Kind regards.

bin/verify-release-artifacts.sh

[Volkan Yazıcı]

I have just pushed this script to `release-2.x`.
Comments are welcome.

I still need to investigate how come we miss file names in the hash files.
I guess some Maven plumbing will be involved there.