rook

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every change submitted to master must go through a Pull Request review process. Every single change (no matter how small) made to the source control repository undergoes review, not just final releases.

Repository on GitHub, which uses git. git is distributed.

Every release is given a unique semantic version, see examples on https://github.com/rook/rook/releases.

Tagging commits for each release with the semantic version of the release is part of the official release process. Tags can be found at https://github.com/rook/rook/tags.

Human readable release notes are included in every release on https://github.com/rook/rook/releases. Major themes of the release, noteable features, breaking changes and deprecations are all captured in these notes, see the latest example from the v0.8 release at https://github.com/rook/rook/releases/tag/v0.8.0.

There are no publicly known vulnerabilities at this time.

Any user can submit bug reports and feature requests from https://github.com/rook/rook/issues, which has a link to https://github.com/rook/rook/issues/new/choose.

All issues are tracked in Github at https://github.com/rook/rook/issues

It would be very rare for an opened bug report on https://github.com/rook/rook/issues to not receive any response at all.

It would be very rare for an opened feature request on https://github.com/rook/rook/issues to not receive any response at all.

All issues are archived and publicly accessible on https://github.com/rook/rook/issues

Security vulnerability and disclosure process is described in depth at https://github.com/rook/rook/blob/master/SECURITY.md

The vulnerability reporting process has facilities to keep reporting/disclosure private, see https://github.com/rook/rook/blob/master/SECURITY.md

No vulnerability reports have been received in the last 6 months.

Non-trivial build file in repository: https://github.com/rook/rook/blob/master/Makefile.

Non-trivial build file in repository: https://github.com/rook/rook/blob/master/Makefile.

The build only uses FLOSS tools as described in https://github.com/rook/rook/blob/master/INSTALL.md#build-requirements, notably make, docker, git and golang.

Unit tests are available and invokable via make test (and go test): https://github.com/rook/rook/blob/master/Makefile Integration tests are available and invokable via go test: https://github.com/rook/rook/blob/master/tests/README.md

Test suites are invokable via go test, the standard for Go.

Unit and integration tests are run with every build. Code coverage numbers are printed for the unit tests. Every PR review includes whether unit tests are included for changes.

Continuous Integration is run on all commits to master branch and the release branches. Also, every pull request has CI run as a quality gate that must be passed before the PR can be merged into master. CI is run on Jenkins and hosted at https://jenkins.rook.io/.

There is not a formal policy instituted, but it is informally enforced during Pull Request reviews by the maintainers and community.

From the release notes of the last major release: https://github.com/rook/rook/releases/tag/v0.8.0 - CockroachDB database support: https://github.com/rook/rook/pull/1777/commits/0b8a8c2b65503f2402235fcbcad40bbe970050eb, https://github.com/rook/rook/pull/1777/commits/f302754c9d6174c40c8a41914afee46857ecce64#diff-61bb4172c3a9030da1df33b3ad18004f - Minio object storage support: https://github.com/rook/rook/commit/7442f8713b833195884f2c1e5cd0d66282c76ff0#diff-309db73e69d22dc6496b8e407b33d353 - Ceph OSDs run in isolation in their own pods, device discovery and provisioning: https://github.com/rook/rook/commit/f1ad88e0ac995e0fd940dc7e09a4fed09f96f3fc, https://github.com/rook/rook/commit/604bb614adf37506c5c81d5c5d42fb36a65009ca

The PR template has check items for adding unit and integration tests. The developer guide also details how to add tests.

The Makefile runs go vet on each build and will fail the build with any vet failures. "go lint" is also supported in the Makefile, and "go fmt" is also run on each build but that is only for syntax. https://github.com/rook/rook/blob/master/Makefile

The Makefile runs go vet on each build and will fail the build with any vet failures. https://github.com/rook/rook/blob/master/Makefile

It is a language feature that the go compiler does not have warning levels, so by default our "go build" is maximally strict. From https://golang.org/doc/faq#unused_variables_and_imports: "Go compiler does not report warnings, only errors that prevent compilation. There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed."

Only publicly published and reviewed cryptographic protocols and algorithms are used.

There are zero cryptographic protocols and algorithms implemented within the Rook project.

All functionality in Rook uses FLOSS.

The delivery of the software from Docker Hub is only performed over https.

No hashes are retrieved over http.

There are no reported vulnerabilities for the project yet.

There are no reported vulnerabilities for the project yet.

No private credentials for docker hub, jenkins, etc. are stored in the repository or leaked.

"go vet" is performed on every build and will fail the build entirely if there are any issues found.

All rules and checks for "go vet" static analysis are enabled by default and will fail the entire build if any issues are found.

Any failure from "go vet" analysis will fail the entire build, forcing issues to be fixed immediately.

Static analysis runs on every single build.

Integrating the gosec tool is actively in progress to avoid security vulnerabilities

The Rook codebase is entirely in golang, which is touted as memory safe (e.g., https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors)