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)? > > 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. Regards, Gilles > > 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]
