Couple of updates below... On Mon, Aug 15, 2016 at 12:26 PM, David Drysdale <[email protected]> wrote: > > Hi Daniel, > > I think there's a few things that aren't ticked but could be: > > - Quality: "It is SUGGESTED that this policy on adding tests be documented > in the instructions for change proposals." - this is included since commit > adc95e6bd68d, with the text "Please update the test suite to add a test case > for any new functionality." in CONTRIBUTING.md > > - Analysis: "At least one static code analysis tool MUST be applied..." - > didn't you turn on Coverity for the project? I seem to remember seeing some > Coverity-triggered fixes. [1]
I've also just added a Clang static-analyzer build variant to the Travis setup. > - Analysis: "It is SUGGESTED that at least one dynamic analysis tool be > applied..." - the Travis builds include running tests under ASAN, LSAN and > UBSAN, so I think this is done. > > - Analysis: "..at least one dynamic tool (e.g., a fuzzer or web application > scanner) be routinely used.." -- close but not quite; we've got a fuzzing > entrypoint, but it's not routinely used. I also pushed some small updates to the fuzzing code and (more usefully) documentation. > - Reporting: "The project's initial response time for any vulnerability > report received in the last 6 months MUST be less than or equal to 14 days." > -- isn't this trivially true, because there haven't been an vulnerability > reports in the last 6 months? > > Process-wise, the main thing that might be a good idea (and which would tick > off 2-3 criteria) would be to decide and document how any potential security > vulnerabilities should be reported. Sadly, it doesn't seem possible with > GitHub [2] atm so we'd need to have something separate. Maybe just adopt > something analogous to the curl [3] process? > > Regards, > David > > [1] I guess this might technically not qualify, because Coverity isn't FLOSS. > If that's the case, I think we should suggest they change the description to > cover things that are free to use for FLOSS projects. > [2] https://github.com/isaacs/github/issues/37 > [3] https://curl.haxx.se/dev/security.html > > > On Mon, Aug 15, 2016 at 11:37 AM, Daniel Stenberg <[email protected]> wrote: >> >> Hey friends, >> >> I finally got my act together and enabled HTTPS for the c-ares web site. I >> intend to redirect all traffic from HTTP to HTTPS unconditionally within a >> day or two. >> >> I also created an entry for c-ares in the CII best practices project and >> started to fill in data for it: >> https://bestpractices.coreinfrastructure.org/projects/291 >> >> We're at 86% right now and I could use a few more sets of eyes on the >> remaining criteria and perhaps some ideas on how to adjust our >> info/processes so that we can reach 100% in a future. >> >> -- >> >> / daniel.haxx.se > >
