On Tue, Jan 4, 2022 at 1:04 PM Ben Laurie <[email protected]> wrote: > > On Tue, 4 Jan 2022 at 17:56, Sam Ruby <[email protected]> wrote: > > > On Tue, Jan 4, 2022 at 11:07 AM Joe Brockmeier <[email protected]> wrote: > > > > > > Hi all, > > > > > > Taking a look at this now. (Meant to yesterday but the weather and > > > Duke Energy had different plans for me.) > > > > > > I'm wondering if some of these stats are going to have the opposite > > > effect than intended. > > > > > > What's the story we want to tell and what do we want to have come out > > > of this meeting / what outcomes are we trying to prevent? > > > > Let me set the context. > > > > We've been invited to a meeting, by Anne Neuberger[1] a person with a > > title of "Deputy National Security Advisor, Cyber & Emerging Tech at > > National Security Council, The White House". According to Bloomberg, > > the same person made the following statements: > > > > * She stated the White House will meet with expertise corporations > > quickly to deal with issues with open-source software. > > * the affected software is broadly used however is nonetheless “hard > > for us to know at the first moment where that code is”. > > * described open-source software as “a witch’s brew” that’s “built by > > volunteers, broadly used, and not managed”. > > > > We don't know much more than that. But the combination of White > > House, deal with, not knowing, not managed is, to put it mildly, > > concerning. > > > > To be clear: the problem is real, and needs to be addressed. We need > > to do our best to ensure that solutions proposed actually address the > > problem, or at a minimum don't make things worse. And we need to be > > prepared for whatever impact those solutions may have on other aspects > > of how we operate. > > > > > We're emphasizing our independence and size with these stats which may > > > be seen as impressive in many contexts but might be seen differently > > > by folks who (and this is the assumption) aren't familiar with open > > > source development or the ASF. 227m lines of code and 630K > > > contributors may be seen as a mountain of problems rather than an > > > impressive achievement. > > > > > > I'd also reverse the order - let's start with security handling + so > > > forth and close with "About the ASF" for folks who are interested. > > > > > > (I snipped a sentence about "without the end user being aware" because > > > it may be seen as alarming, but also it contradicts the section later > > > that notes that distributors are required to notify end users due to > > > section 4a of the Apache License.) > > > > More context. > > > > We had a vulnerability in log4j. We can tell with precision when the > > vulnerability was introduced and which releases of our code are > > affected. > > > > We have no way of knowing what commercial and open source products > > incorporate log4j. > > > > We have no way of knowing what downstream users may be using those > > products, and which versions of our software they may have been > > provided with. > > > > Yes, our license requires our license to be communicated to end users, > > but that's not enough information to determine who is affected. > > > > Things we need to communicate: > > > > * Yes, contributions are voluntary, but contributions in general, and > > contributions to log4j in specific, are made and vetted by seasoned > > professionals. > > > > * Yes, we manage our software, and do so transparently in a way that > > can readily be audited, but only to the point of release. > > > > I do think we should have an explicit goal to provide (ideally industry > standard) APIs that allow downstream projects to use the results of such > audits in their own audits.
Just so I'm clear, are you referring to something like software bill of materials, as described by the following? https://www.linuxfoundation.org/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/ > > > > - Sam Ruby > > > > [1] https://www.linkedin.com/in/anne-neuberger-13b4491b > > > > [2] > > https://mywinet.com/some-federal-systems-affected-by-software-flaw-us-official-says/ > > > > --------------------------------------------------------------------- > > 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]
