hristian Grobmeier (binding)
> > Carter Kozak (binding)
> > Matt Sicker (binding)
> > Volkan Yazıcı (binding)
> >
> > +0:
> > Xeno Amess (non binding)
> > Dominik Psenner (binding)
> >
> > The PMC decided unanimously to introduce the aforemen
gory (binding)
> Christian Grobmeier (binding)
> Carter Kozak (binding)
> Matt Sicker (binding)
> Volkan Yazıcı (binding)
>
> +0:
> Xeno Amess (non binding)
> Dominik Psenner (binding)
>
> The PMC decided unanimously to introduce the aforementioned CVE
> creation proce
introduce the aforementioned CVE
creation process.
Kind regards,
Volkan
[1] Note that this process only involves the creation of CVEs and
doesn't interfere with any form of fixes or releases.
[2] An action with lazy approval is implicitly allowed unless a -1
vote is received, at which time, depending on the type
+1 (with lazy approval)
On Mon, Jan 3, 2022 at 12:59 PM 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`
+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)
+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
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
+-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
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
> -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
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
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
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
+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.
>
+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,
+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.
>
>
[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)
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
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,
>
>
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
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
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
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
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
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
25 matches
Mail list logo
