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