VAST

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 cut release candidates with a feature freeze period until the actual release, see anything with a -rc* suffix on https://github.com/tenzir/vast/releases

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

We use SemVer, see https://github.com/tenzir/vast/releases

We use annotated tags for our releases at https://github.com/tenzir/vast/releases

Non-trivial release notes file in repository: https://github.com/tenzir/vast/blob/master/CHANGELOG.md.

There is an additional written summary in https://github.com/tenzir/vast/releases and in the blog at https://vast.io/blog

We did not have a CVE yet, but we do have a security policy at https://github.com/tenzir/vast/security/policy

See bug report template at https://github.com/tenzir/vast/issues/new/choose, and

There is an issue tracker at https://github.com/tenzir/vast/issues, and there is an additional issue tracker that is not open to the public. We are looking to move to an open roadmap.

See pull requests labeled 'bug' that were recently merged: https://github.com/tenzir/vast/pulls?q=is%3Apr+is%3Aclosed+label%3Abug

Most of the requests come in via our Community Slack channel at slack.tenzir.com; there are no public metrics on this, but >90% of the requests of the past year were done within 3 months.

Most of the communication takes place in GitHub pull requests directly on https://github.com/tenzir/vast/pulls

See security policy at https://github.com/tenzir/vast/security/policy

See security policy at https://github.com/tenzir/vast/security/policy

Did not have any vuln reports in the past 6 months.

Non-trivial build file in repository: https://github.com/tenzir/vast/blob/master/CMakeLists.txt.

Non-trivial build file in repository: https://github.com/tenzir/vast/blob/master/CMakeLists.txt.

All dependencies are open-source; a full list is available at https://vast.io/docs/setup-vast/build#dependencies

There is extensive CI that is required to succeed before a PR may be merged; every change has to go through the PR workflow. See here for a list of past runs: https://github.com/tenzir/vast/actions

The testing is invocable using cmake; run the build targets 'integration' to run integration tests, and 'test' to run unit tests.

There's an ever increasing test coverage of ~80%. We're in the process of adding this to our CI.

There is extensive CI that is required to succeed before a PR may be merged; every change has to go through the PR workflow. See here for a list of past runs: https://github.com/tenzir/vast/actions

This is part of the review workflow. No change gets merged without having at least one approval from the team, with an explanation on how it was tested.

Should be visible from past pull requests, e.g., see the review comment history on this recent PR: https://github.com/tenzir/vast/pull/2493

There is some documentation on this throughout our contribution guide at https://vast.io/docs/develop-vast/contributing/

We enable -Wall -Wextra and a few other warnings by default.

See also: https://github.com/tenzir/vast/blob/017de2f9ec156c80655ec6ac3765a2476a2142b3/CMakeLists.txt#L304-L316

We build using -Werror in CI, which is mandatory for passing. This causes CI to treat warnings like errors and to fail the CI run. This enforces that the project builds on master without warnings.

See also: https://github.com/tenzir/vast/blob/017de2f9ec156c80655ec6ac3765a2476a2142b3/CMakeLists.txt#L304-L316

See here for the list of enabled warnings in our CMake configuration: https://github.com/tenzir/vast/blob/017de2f9ec156c80655ec6ac3765a2476a2142b3/CMakeLists.txt#L304-L316

This should be met by the four most senior developers on the team. GitHub usernames are mavam, tobim, dominiklohmann, lava

Not really sure how to "prove" this.

This should be met by the four most senior developers on the team. GitHub usernames are mavam, tobim, dominiklohmann, lava

Not really sure how to "prove" this.

We only re-use cryptographic routines from OpenSSL and do not implement them ourselves.

We only use cryptographic functions via OpenSSL.

Only cryptographic dependency is OpenSSL, which is FLOSS.

This is not applicable to our project directly. We use CAF's OpenSSL layer for networking (see https://github.com/actor-framework/actor-framework), and do not implement this in VAST directly.

This is not applicable to our project directly. We use CAF's OpenSSL layer for networking (see https://github.com/actor-framework/actor-framework), and do not implement this in VAST directly.

This is not applicable to our project directly. We use CAF's OpenSSL layer for networking (see https://github.com/actor-framework/actor-framework), and do not implement this in VAST directly.

This is not applicable to our project directly. We use CAF's OpenSSL layer for networking (see https://github.com/actor-framework/actor-framework), and do not implement this in VAST directly.

The software has no user authentication.

The software generates no cryptographic keys.

The software uses CAF's OpenSSL layer for networking (see https://github.com/actor-framework/actor-framework), which uses a TCP connection with OpenSSL.

Software does not communicate over HTTP.

No known public vulnerabilities.

No known public vulnerabilities, so I assume this applies.

This would be considered a vulnerability in VAST, and as far as I know there is no such thing.

We use address sanitizer and thread sanitizer in all debug builds (verified in CI), and there's an option to enable undefined behavior sanitizer which passes local builds (not in CI because of timeout limitations).

We also have a clang-tidy configuration that we follow for all newly added code; this is additionally enforced in CI.

See for example the clang-tidy configuration https://github.com/tenzir/vast/blob/master/.clang-tidy

This is enforced by CI: PRs with failing checks cannot be merged.

Occurs for every PR; branch protections on GitHub ensure that PRs with failing checks cannot be merged, be that tests or static analysis failures.

There are additional checks at runtime enforced via assertions for non-release builds. There is a suite of end-to-end tests that must pass CI here, that all run with assertions enabled: https://github.com/tenzir/vast/blob/master/vast/integration/vast_integration_suite.yaml

We are in the process of integrating fuzzing via Code Intelligence. There's a WIP example here that we intend to upstream in the near future: https://github.com/tenzir/vast-fuzzing

This is not currently being done before every release, but will be automated in the future.

We are in the process of integrating fuzzing via Code Intelligence. There's a WIP example here that we intend to upstream in the near future: https://github.com/tenzir/vast-fuzzing

Assertions are enabled by default for debug builds, see https://github.com/tenzir/vast/blob/017de2f9ec156c80655ec6ac3765a2476a2142b3/CMakeLists.txt#L361-L379

Assertions cause CI to fail so newly added code that causes assertions to trigger cannot be merged. In the future, we intend to run fuzzing on a schedule, with the additional internal requirement to fix problems found via fuzzing in a timely manner.