Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete badging process for CII Best Practices #2700

Open
4 of 6 tasks
dpseidel opened this issue Jun 14, 2018 · 1 comment
Open
4 of 6 tasks

Complete badging process for CII Best Practices #2700

dpseidel opened this issue Jun 14, 2018 · 1 comment

Comments

@dpseidel
Copy link
Member

@dpseidel dpseidel commented Jun 14, 2018

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 dpseidel self-assigned this Jul 11, 2018
@dpseidel
Copy link
Member Author

@dpseidel dpseidel commented Jul 31, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants