On Sun, Jan 9, 2022 at 9:21 AM Gilles Sadowski <[email protected]> wrote: > > Hello. > > Le dim. 9 janv. 2022 à 10:38, Mark J Cox <[email protected]> a écrit : > > > > 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. > > Does the 4-bullets list really add any condition? > Isn't > ---CUT--- > We REQUIRE redistributed versions of our code to comply with the > terms of our license > ---CUT--- > redundant with the licence itself? > Isn't > ---CUT--- > We REQUIRE any reports of security issues to follow the process we > have defined for such > ---CUT--- > restating the policy already in place (i.e. using "require" here is actually > not an additional constraint)?
I think Mark is right, and the issue can easily be avoided. For now just imagine a prominent "How to Keep Up To Date" link in strategic places. Just having that link will both remind and set expectations. Perhaps the summary at the top of https://cwiki.apache.org/confluence/display/COMDEV/Position+Paper could give some insight as to how the page should be structured. Friendly, helpful things like: * How to keep informed * How to participate * What to look for I will say that I've learned a lot while contributing to that page. I don't feel like we need to wait for the White House to take action ourselves. > > 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" > > Indeed, the above list is a clear summary of not very widely shared > knowledge. > Perhaps it should be required that it appears in the announcement > of every new release. Great idea: announcements are also a good place to put a link such as the one we are describing. > Regards, > Gilles - Sam Ruby > > 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 > > > > > > > > --------------------------------------------------------------------- > 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]
