> I don't see how VEX introduces a new risk here. It really depends on whether the VEX entry states: "Not affected" or "Possibly not affected". As you see in my responses - those are exactly what I am explaining in my responses is exactly what you explained. In one of those issues I responded to the user that "we do not use that affected functionally, so likely we are not affected". But yet the user demanded, and expected and was very persistent about it, to have 100% certainty and an authoritative answer.
I am absolutely fine in putting in VEX: * don't know, did not check (when we did not want to spend days investigating it and it's difficult) * possibly not affected (when we think we are not affected) * affected, please upgrade (when we know) All those are fine, and if in the VEX we will be able to do it and be very clear that this is the meaning, I am perfectly fine with it. But I would - under any circumstances - never put "Certainly not affected" there. And this is what all commercial users will be expecting. None of the above answers (except affected) is satisfying to the consumer of VEX if you ask me and it's pretty useless. J. On Thu, Feb 6, 2025 at 9:10 AM Mark Thomas <[email protected]> wrote: > On 05/02/2025 14:53, Jarek Potiuk wrote: > >> If this is true, then I don't see how anyone, ever, would issue a > > "not affected" statement as mentioned by Arnout. > > > > Yep. I don't see it either. I would not do it for sure if I knew what > legal > > implications it brings. > > > > This is why my response to those questions are like this: > > > https://github.com/apache/airflow/discussions/44865#discussioncomment-11656354 > > and this https://github.com/apache/airflow/discussions/40590 and I would > > never, ever respond differently. > > > > It makes some of our users angry, but I don't see how I can answer > > differently currently without putting ASF and myself at risk. Not until > we > > have clarity on how to do it at least. > > I think risk of the scenario outlined a couple of messages earlier in > this thread (and shown below) happening is very low. > > The statement that Apache ABC is "not affected" by a CVE is no different > to the statement that the CVE "is mitigated" in Apache ABC by doing X. > > We (and everybody else writing software) have been doing the latter for > years. Sometimes we get it wrong, and the result is simply a new CVE > with the updated (hopefully complete) mitigation. > > I don't see how VEX introduces a new risk here. > > Statements around CVEs have always had the implied caveats of "To the > best of our knowledge...", "As as as we are aware..." etc and I don't > see why VEX statements should be any different. > > I certainly doesn't hurt to be more explicit about stating these caveats > and I think there are benefits to being explicit. But I don't think > there is a big new risk here. > > Mark > > > > J. > > > > > > On Wed, Feb 5, 2025 at 3:44 PM Gilles Sadowski <[email protected]> > wrote: > > > >> Hi. > >> > >> Le mer. 5 févr. 2025 à 13:51, Jarek Potiuk <[email protected]> a écrit : > >>> > >>> And let me repeat what I wrote on slack today: > >>> > >>> For ASF the legal risk is huge. If someone gets billions of dollars in > >>> damage because they trusted we told them "we are not vulnerable to this > >>> 3rd-party vulnerability" - they might sue ASF and demand all our > >> trademarks > >>> as compensation (not the money we have in the bank). This is is a HUGE > >> risk > >>> for ASF and the whole open-source community if you ask me. > >> > >> If this is true, then I don't see how anyone, ever, would issue a > >> "not affected" statement as mentioned by Arnout. > >> > >> Regards, > >> Gilles > >> > >>>> [...] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: > [email protected] > >> For additional commands, e-mail: > >> [email protected] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > >
