Re: [DISCUSS] Starting social media accounts for subprojects

+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

RE: Forwarding email per Matt Sicker suggestion

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

Re: [DISCUSS] Starting social media accounts for subprojects

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,

Re: [DISCUSS] Starting social media accounts for subprojects

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.

Re: Forwarding email per Matt Sicker suggestion

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 < >

[DISCUSS] Starting social media accounts for subprojects

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,

Re: CVE creation process

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, > >

Re: CVE creation process

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

Re: CVE creation process

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

Re: CVE creation process

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

Re: CVE creation process

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

Re: CVE creation process

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

Re: rat:check at verify

+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

Re: rat:check at verify

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.

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

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

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

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

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

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

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

+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

CVE creation process

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

bin/verify-release-artifacts.sh

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.