My reading of your use of that extra "REQUIRE" is to put additional conditions on users of our software, and I'd be completely against that.
We can certainly help by ensuring our users and downstream re-packagers know what to do though, creating something that explains - all issues in non-EOL software that ASF projects believe are vulnerabilities will get CVE names - you should subscribe to [email protected] (and preferably dev/ [email protected]). - All vulnerability CVE reports and new release announcements are sent to those lists - All vulnerability CVE reports are pushed to the cve.org project with machine readable metadata around released versions - If you find a new vulnerability here's how to report it - (maybe highlight somewhere if you report an issue to us according to our policy we will credit the finder on their request) - Projects will from time to time become EOL and we'll announce that on the same lists, on the projects web page. Unfixed vulnerabilities may exist in EOL projects and they are not guaranteed to all have CVE names. A lot of this is implied but not called out explicitly "here's what you should do after you've downloaded something" EOL is where we have some work to do internally; ensuring that projects that become inactive or unresponsive or moved to the attic do end up with those quite clear notices. Regards, Mark On Fri, Jan 7, 2022 at 11:06 PM Sam Ruby <[email protected]> wrote: > In producing the written materials for the upcoming Security Summit at > the White House, it was very helpful that we had plenty of documentation > for our processes and procedures on the Apache web site. We document > what is expected of contributors, project management committees, > releases, responses to security vulnerabilities, etc. All good. > > It occurs to me that we are missing an opportunity to document what is > expected of people downloading our releases, in particular our > expectations we have for redistributors. > > The list is small. An outline: > > * We REQUIRE redistributed versions of our code to comply with the > terms of our license > * We ENCOURAGE reviews of the code, in particular reviews of the code > in the context in which it is deployed (i.e., including other > components that this code may interact with) > * We REQUIRE any reports of security issues to follow the process we > have defined for such > * We EXPECT redistributors to keep current with respect to our > releases and actively push out fixes > > If these expectations are spelled out in a friendly way, and there are > prominent links to these expectations in strategic locations (e.g., > download pages), then perhaps we will see greater awareness of security > responsibilities. Whether or not it moves the needle is an open > question, but at a minimum could be helpful to point the press to the > next time a vulnerability is discovered. > > Thoughts? > > - Sam Ruby > >
