Choria.io

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.

we do nightly builds and roughly monthly releases of master, no interim builds are done other than nightlies - those are publishes as RPMs.

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

semver, see github releases.

we use tags as per github releases process

Non-trivial release notes file in repository: https://github.com/choria-io/go-choria/blob/master/CHANGELOG.md.

We have not had CVEs

github issues, covered in CONTRIBUTING.md but every project has github issues, its the only supported process. https://github.com/choria-io/go-choria/issues

as above, github issues.

We acknowledge every report pretty much on the day it's filed.

We either accept it and work on it in some way or close it after explaining to reporters its not a priority, we have old issues but they are kind of our internal project tracking.

https://github.com/choria-io/go-choria/issues

org wide security process https://github.com/choria-io/go-choria/security/policy

private email address given in https://github.com/choria-io/go-choria/security/policy

initial response of 48 hours detailed in https://github.com/choria-io/go-choria/security/policy

Non-trivial build file in repository: https://github.com/choria-io/go-choria/blob/master/Rakefile.

Non-trivial build file in repository: https://github.com/choria-io/go-choria/blob/master/Rakefile.

All the packaging is open source and in fact users building their own builds is common.

We use CircleCI in each project

go test, rake spec etc, all normal stuff

We do our best.

Nightly builds for key components integrated, packaged etc.

This is generally the expectation yes.

An example of a recent community contributed Open Policy Agent support https://github.com/choria-io/mcorpc-agent-provider/pull/146/files extensively tested etc. This is generally the pattern we follow when it makes sense.

we use linters, external tools like codefactor.io, rubocop, staticcheck, go vet, spellcheck etc

PRs will not go green without, we don't merge on red.

staticcheck and others mentioned are all generally without configuration and on strict mode.

As the lead dev I have decades of experience in this field, have worked in secure government environments, under various frameworks like SOX and more. Choria itself have been security audited by major fortune 100s.

As the lead dev I have decades of experience in this field, have worked in secure government environments, under various frameworks like SOX and more. Choria itself have been security audited by major fortune 100s.

we use bcrypt when this storing this kind of information is needed

Tend to be handled by go crypto/rand

packages via packagecloud.io over https

Kind of built into the RPM/Debian distribution mechanisms

not had disclosed vulnerabilities.

have not had any, but we do have a policy.

staticcheck

github does vulnerability checks now

PRs would be red, we do not merge red, so they have to be fixed.

on every PR and post merge to master

n/a