umoci

umoci currently maintains the latest version of the project, and currently new versions are backwards-compatible with old versions (requiring no upgrade path work). When we start releasing major releases we will document the upgrade path, and provide a transition period (where both versions will be maintained).

Users may submit issues through the GitHub issue tracking system https://github.com/opencontainers/umoci/issues.

We have not had any vulnerability reports in the last 12 months, however if we do we will include them in the release documentation as we do all other contributors to the project.

This process is documented in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

This information is documented in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

This is automatically done with gofmt, as described in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md. This is done as part of our CI for every commit.

We use GNU make which honors such build flags. We also provide additional build flags in accordance with the community standards of Makefile build flags.

We do not have any subdirectory build systems, only a top level Makefile.

The Go programming language supports this natively https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/. In addition, we have checks in our automated CI to make sure that the binaries are reproducible in a "trivial" fashion with make local-validate-reproducible.

umoci provides "make install" and "make uninstall".

umoci installs files onto a POSIX system, and thus "make install" (and "make uninstall") obey variables such as DESTDIR, PREFIX, BINDIR, MANDIR.

All project results can be installed with make install and all tests can be run with make test. Docker is used to make the test environment consistent without developers needing to install any additional programs.

The full set of external dependencies are vendored into our source code and can be fetched with our vendor.sh script https://github.com/openSUSE/umoci/blob/master/hack/vendor.sh. We plan to switch to vndr in the near future.

We monitor our upstream dependencies which are stored in the standard Go vendor directory.

We make use of the Go standard vendor directory, and do not copy the code. The exception to this is the third_party directory, which contains code that we have heavily modified from other projects (however we track changes in the upstream versions).

We do not use deprecated or obsolete functions and APIs (this is checked by govet in the case of standard Go library functions, and external libraries are tracked for deprecation notices).

We have an automated test suite run for every commit, as described in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

Part of our process is creating regression tests, as described in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

We generate coverage profiles for every CI run. The CI will fail if the coverage is less than 80% for any one of the images that we test against, and we do not merge commits that have failed CI https://github.com/opencontainers/umoci/blob/v0.4.0/hack/ci-coverage.sh#L32-L38.

This is part of our policy for contribution, as described in https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

This information is included in the project's CONTRIBUTING.md file https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.

The Go compiler does not emit warnings, and our test suite will automatically fail if any of the linters we use produce warnings.

umoci is implemented with secure design principles in mind. Details of the security model and considerations are outlined in https://umo.ci/reference/security/.

This tool makes use of the sha256 and several other standard hashing algorithms which are still considered to be secure. In addition, the algorithms used are mandated by the OCI specification.

This project does not store authentication credentials or private cryptographic keys.

This project does not support network communication.

This project does not use TLS.

This project does not use TLS.

This project does not use TLS.

All releases artefacts (the source code and binaries) are signed using the project's PGP keys. This process is also automated. The private keys are kept by the maintainers and are not publicly accessible.

All git release tags are signed by the same key used for signing release artifacts.

Input in the form of JSON and tar archives are all verified by the respective Go libraries, and in addition we do some verification of the OCI image before and while we operate on it -- such as verifying the CAS hashes match the files https://github.com/opencontainers/umoci/blob/v0.4.3/oci/layer/unpack.go#L255-L275 and https://github.com/opencontainers/umoci/pull/282.

While Go doesn't provide many hardening mechanisms, we do use -buildmode=pie to enable ASLR https://github.com/opencontainers/umoci/blob/v0.4.3/Makefile. We also additionally have several protections such as making extracted filesystems world-inaccessible by default https://umo.ci/reference/security/, as well as working actively on protecting against container escapes (though this is something still being worked on https://github.com/opencontainers/umoci/issues/277).

We have a security model and description of how this model is implemented in https://umo.ci/reference/security/. It will be updated as-necessary.

govet is specifically written to look for "suspicious constructs" https://golang.org/cmd/vet/. In addition, we use gosec to find potential security issues (such as not checking error values). https://github.com/securego/gosec/.

Go is not a memory unsafe language.