Subject: Re: HTTPS and best practices for c-ares

Re: HTTPS and best practices for c-ares

From: David Drysdale via c-ares <c-ares_at_cool.haxx.se>
Date: Wed, 17 Aug 2016 12:04:31 +0100

Couple of updates below...

On Mon, Aug 15, 2016 at 12:26 PM, David Drysdale <drysdale_at_google.com> 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 <daniel_at_haxx.se> 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
>
>
Received on 2016-08-17