parsec

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.

All project state is held in the public repository in Github where all the development happens.

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

Versioning for the Parsec service uses semver, which mandates unique identifiers

All release versions are tagged appropriately in Github: https://github.com/parallaxsecond/parsec/tags

Non-trivial release notes file in repository: https://github.com/parallaxsecond/parsec/blob/main/CHANGELOG.md.

No publicly known vulnerabilities have so far been identified.

Bugs can be reported as Github issues: https://github.com/parallaxsecond/parsec/issues

Individual issues are tracked under the feature with the same name in Github: https://github.com/parallaxsecond/parsec/issues

We strive to acknowledge and fix all bug reports as soon as possible.

We acknowledge and discuss publicly all enhancement requests we get from the community.

All of our reports and responses can be found under https://github.com/parallaxsecond/parsec/issues?q=is%3Aissue

The process for reporting vulnerabilities is described under https://github.com/parallaxsecond/parsec/security/policy

The process is described here: https://github.com/parallaxsecond/parsec/security/policy - we accept vulnerability reports to the maintainers email list, cncf-parsec-maintainers@lists.cncf.io

No vulnerabilities have been reported in the last 6 months

The project uses Rust, for which the Cargo toolchain can rebuild the software from source given that the correct dependencies are found locally.

Cargo is the typical build tool for Rust projects.

Cargo and the rest of the toolchain required is FLOSS

We provide extensive documentation on our testing frameworks and how they can be used locally: https://parallaxsecond.github.io/parsec-book/parsec_service/tests/index.html All our CI framework can also be found open-source in the repository in form of scripts and tests: https://github.com/parallaxsecond/parsec/blob/main/ci.sh https://github.com/parallaxsecond/parsec/tree/main/e2e_tests Our CI pipeline is fully open-source: https://github.com/parallaxsecond/parsec/tree/main/.github/workflows https://github.com/parallaxsecond/parsec/tree/main/.circleci

Testing is done in a typical way for Rust projects, with the sole difference that the testing framework resides in its own Rust crate: https://github.com/parallaxsecond/parsec/tree/main/e2e_tests

We maintain CodeCov reports for the parts of the project which we can test and instrument, and the code coverage is currently around 65%: https://app.codecov.io/gh/parallaxsecond/parsec

Code is routinely tested on each change using Github Actions and CircleCI: https://github.com/parallaxsecond/parsec/tree/main/.github/workflows https://github.com/parallaxsecond/parsec/tree/main/.circleci

A testing policy exists for new features in our PR guidelines: https://parallaxsecond.github.io/parsec-book/contributing/pr_checklist.html

We strive to test all new functionality when possible.

As an example, a list of features delivered in the most recent release (0.7.0) and a description of tests implemented for them is given below: * Adding support for admin clients in the service: both the PR where the admin configuration option is added ( https://github.com/parallaxsecond/parsec/pull/316 ) and the PR where the admin operations are added ( https://github.com/parallaxsecond/parsec/pull/318 ) include testing * Adding two new providers, CryptoAuthLib, for which we had an open issue to produce a suitable testing framework ( https://github.com/parallaxsecond/parsec/pull/318 ) and the work for building the framework is ongoing; and the Trusted Services provider, which is already integrated in the testing framework ( see trusted-service-provider job in https://github.com/parallaxsecond/parsec/blob/main/.github/workflows/ci.yml ), though without code coverage checks for now.

A testing policy exists for new features in our PR guidelines: https://parallaxsecond.github.io/parsec-book/contributing/pr_checklist.html

We use clippy, a tool for linting and code checking packaged in the default Rust toolchain, for linting.

The warnings must be addressed for each change, as the clippy checks are incorporated in the CI pipeline.

CI clippy checks are as strict as we could get them to be.

The two main maintainers and contributors - Hugues de Valon and Ionut Mihalcea ( https://github.com/parallaxsecond/parsec/graphs/contributors ) - have experience in designing and developing secure software and have been trained for this purpose.

The two main maintainers and contributors - Hugues de Valon and Ionut Mihalcea ( https://github.com/parallaxsecond/parsec/graphs/contributors ) - have experience in designing and developing secure software and have been trained for this purpose.

The Parsec project has a big part of its functionality involved in cryptography. However, all of the cryptographic APIs exposed or consumed by us are part of cryptographic specifications that have been devised by experts. For the APIs that we expose we also receive continuous help and feedback from experts in this field.

Our main goal is to bridge between different cryptography APIs and interfaces. None of the cryptographic functionality that is exposed by the Parsec service is implemented by us, but is, instead, delegated to hardware backends or software implementations produced by experts.

All functionality in the project is implementable as FLOSS.

For the cryptographic algorithms that we use internally we strive for key lengths way beyond the requirements given here, e.g. for communication with physical TPMs we aim for encryption with 256 bit AES keys. Note, however, that since our service bridges between cryptography APIs, clients of the service can actually access smaller key lengths (e.g. 1024 bit RSA keys).

Our security mechanisms do not depend on broken cryptographic algorithms, but we do expose some as an option in our crypto API (e.g. MD5).

No modes with security weaknesses are used in the software, but we do expose some as an option in our crypto API (e.g. SHA-1).

No key agreement protocols are used within the service, but we do expose algorithms that do not implement perfect forward secrecy through our API.

We do not handle passwords for our clients.

All keys and nonces are generated using the backends that we rely on and that we can trust to be a CS(P)RNG.

Our current interface is for local connections using sockets, for which we can trust the OS against MitM attacks.

No such exchange exists

No vulnerabilities have been reported.

No vulnerabilities have been reported.

There are no private credentials that could be leaked in the public repositories.

Using the Rust compiler together with the clippy linter catches most (if not all) of typical vulnerabilities found in languages such as C/C++. Extra tooling for identifying such vulnerabilities is not needed (and not standard in the development process for Rust projects).

Static analysis tools are not generally used for Rust projects.

Static analysis tools are not generally used for Rust projects.

Static analysis tools are not generally used for Rust projects.

Project is written in memory-safe language.