On 21/12/2021 09:35, Hen wrote:
On Mon, Dec 20, 2021 at 1:35 AM Mark J Cox <[email protected]> wrote:
Mark is right; we've got several hundred projects and they all work
differently. Some have lots of resources, handle lots of issues, and have
mature and working processes for getting releases out. Others either handle
security issues infrequently or are struggling for resources and we need to
give them some help. The ASF security team provides and maintains the
common required process all projects need to follow to handle their
reported security issues, and we provide as much help and guidance as we
can on how they can get through them. (the yearly report gives a good
overview, here's the one for 2020:
https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
)
Thanks :)
I also enjoyed finding https://www.apache.org/security/projects.html as a
nice list of the various Security project-teams.
My assumption on the history is that initially the Security Team was HTTP
Server focused (yourself, Bill? Ben?), and then as Tomcat grew the Tomcat
Security work led to MarkT joining in. Are others of the projects with
mature processes finding themselves getting more involved in the overall
Security Team as a whole? I wonder if there are clumping strategies we
could use; for example I imagine despite not being listed that the Tomcat
Security team handle Commons FileUpload [assuming I'm not way out of date
and it's still used].
The Commons team handle that. While I am on the Commons PMC, I don't get
too involved in the Commons security issues apart from the odd bit of
advice from time to time.
Those projects that struggle for resources need help from more than what a
PSIRT-like team can provide; what they need are people in their project
able to write and test code, able to do releases, people that really
understand how the project is used and the community around it.
My initial instinct is that "sure, but that's just projects becoming
inactive". Which I think is true, but I wonder if you're saying that
inactive projects are one of our larger security-related issues?
The inactive projects will have been moved to the attic. A bigger issue
- in my view - is the projects that are on the cusp of moving to the
attic. They have enough activity to move forward just enough to avoid
the attic but not enough to react to a security issue. There are
projects that have vulnerabilities that have remained unaddressed for
far too long.
Too long is subjective and will vary by circumstance but I think there
comes a point when a project's failure to make meaningful progress to
address a security issue in a reasonable time frame should result in the
project being moved to the attic.
It's a hard one to fix, assuming it should be fixed. Personally I think
there should be some kind of alert when a project moves to the Attic.
There should be an email to announce@.
Email to all PMCs would likely be noise for most PMCs and targetting an
email would require knowledge of dependencies.
Generally, I'd expect projects to be reviewing their dependencies fairly
regularly.
Common Deprecation Event :) And possibly the 'investment' is in putting
more energy into how to move off of the now mothballed project.
What do we do when a security issue is reported in an Attic'd project?
It would normally be rejected as the project is no longer supported.
Mark
I'd also like to see us have people work more closely with the various
OpenSSF initiatives. OpenSSF have a number of interesting projects that
are trying to understand and address problems that have come up with OSS
many of which would benefit from people with security and specifically
Apache projects experience.
As in, if you had a volunteer today you would ask them to volunteer to the
OpenSSF, or you'd like to connect some of the mature security-minded
projects to the OpenSSF, or ... ?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
