A few minor typo corrections in-line and one potential additional topic.
On 31/12/2021 19:06, Sam Ruby wrote:
In addition to the in-person meeting next month, we are invited to send
read-ahead material and there will be a brief phone call. Given that
the call will only last 30 minutes, I presume that call will be consumed
by introductions, logistics, and perhaps questions about the read-ahead
material. That call will be on Wednesday, so I would like to send any
read-ahead material that we might have late morning EST on Monday.
My thoughts are to lead with a summary/bulletized version of what has
been discussed recently on this list, followed by actual pointers to the
original emails. Here's a first draft... additions/corrections welcome,
both to the bullet points and new posts (preferably to this list) that
should be added.
Key bullet points
* This will require collective action
o There are things we can do, both individually and together, to
reduce the number of vulnerabilities.
o There are things, such as SBOMs, that can help identify what is
affected once a vulnerability is found.
o Much of this is moot if patches are never applied.
* Volunteers/community/participation
o Out contributors tend to be seasoned software professionals
whose employers include ASF releases in their commercial products.
Out -> Our
o Our communities are healthy, open, and transparent.
o Companies an government agencies that want to help don't need
money or formal contracts to do so. Join our mailing lists,
review our code, contribute fixes.
an - > and
One side-effect of the original log4j issue is that a lot more eyes have
been focused on that code. As a result of this increased scrutiny, there
have been a handful of additional security issues identified. I think we
need to make clear that we view this as a good thing.
This isn't unique to log4j. We have seen it in other projects as well.
Generally, the more severe the issue, the more security researchers are
attracted to look at the code more closely.
This additional scrutiny on the original issue, the applied fix, the
surrounding code and any similar functionality is something that only
happens with open source. This is because security researchers have free
access to the source and the fix and are able to go and poke around and
see what else they can find. It is a lot harder (arguably impractical)
to do something similar with closed source.
Mark
Background reading:
* EO - Mark Cox - https://s.apache.org/3nctr
* SBOM - David Nalley - https://s.apache.org/hccur
* Applying updates - Mark Thomas - https://s.apache.org/5jqab
* Collective action - Phil Steitz - https://s.apache.org/ljzn0
* Volunteers - Sam Ruby - https://s.apache.org/3vkpr
* Contributors/maintenance - Dominik Psenner - https://s.apache.org/3lrk1
* CISA - David Nalley - https://s.apache.org/1gr1c
* Get Involved - https://www.apache.org/foundation/getinvolved.html
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
