So we don't lose any of these great ideas I've added a https://cwiki.apache.org/confluence/display/COMDEV/Brainstorm+Initiatives sub page and linked to a few of them.
Regards, Mark On Sun, Jan 9, 2022 at 3:15 PM Sam Ruby <[email protected]> wrote: > 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] > >
