Complete badging process for CII Best Practices

[dpseidel]

https://bestpractices.coreinfrastructure.org/en/projects/1927/

Updates required for passing badge:

• update documentation with minimal security language
• update contributing.md with policy indicating tests policy for new features.
• provide reference documentation that describes the external interface (both input and output) of ggplot2
• HTTPS for ggplot2.tidyverse.org
• Review Dynamic/Static Analysis requirements
• Review remaining Security and Quality requirements

[dpseidel]

Passing

The only thing keeping us from a passing build is security:

The project MUST have at least one primary developer who knows how to design secure software.

This is self reported. We could probably hedge this and say that it is not applicable or that we have many developers aware of how to develop secure libraries for R.

A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature.

This is a delivery/CRAN question and not particularly relevant to package libraries, quite possibly this is already met?

Silver

requires:

• code of conduct
• document testing policy
• document governance model
• document roles and responsibilities
  perhaps owner/maintainer/author/contributor designation is enough?
• document security requirements

what the user can and cannot expect in terms of security from the software produced

• document vulnerability report process
• document security assurance case

The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered.

• automatic style enforcement if available (lintr, styler?)
• 80% test coverage
• post passing badge on front page (along with other achievements/badges)

suggests:

• a public contributor license

The project SHOULD have a legal mechanism where all developers of non-trivial amounts of project software assert that they are legally authorized to make these contributions. The most common and easily-implemented approach for doing this is by using a Developer Certificate of Origin (DCO), where users add "signed-off-by" in their commits and the project links to the DCO website. However, this MAY be implemented as a Contributor License Agreement (CLA), or other legal mechanism.

Currently at 60%

Gold

requires

• a copyright statement added to each source file
• a license statement added to each source file
• issue badging indicating beginner friendly or small tasks for casual or novice contributors
• encrypted 2FA for contributors changing master
• document code review practices
• 90% statement coverage
• 80% branch coverage

If ggplot2 moves forward on either of these, beyond the documentation improvements, the security and build requirements should have a second review with more seasoned eyes.