https://github.com/sigstore/sigstore-conformance
Conformance testing for Sigstore clients
https://github.com/sigstore/sigstore-conformance
conformance sigstore tests
Last synced: 4 months ago
JSON representation
Conformance testing for Sigstore clients
- Host: GitHub
- URL: https://github.com/sigstore/sigstore-conformance
- Owner: sigstore
- Created: 2022-09-27T03:54:22.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2025-06-19T07:54:03.000Z (12 months ago)
- Last Synced: 2025-06-19T08:42:07.652Z (12 months ago)
- Topics: conformance, sigstore, tests
- Language: Python
- Homepage: https://sigstore.dev
- Size: 332 KB
- Stars: 9
- Watchers: 9
- Forks: 13
- Open Issues: 27
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
sigstore-conformance
====================
[](https://github.com/sigstore/sigstore-conformance/actions/workflows/ci.yml)
[](https://github.com/sigstore/sigstore-conformance/actions/workflows/conformance.yml)
`sigstore-conformance` is a conformance testing suite for Sigstore clients.
Test results for known clients are published daily in the
[Sigstore Client Conformance Report](https://sigstore.github.io/sigstore-conformance).
This suite provides a high-level view of client behaviour as a whole and sets
out to answer questions such as:
- Does the client fail when given a signing certificate that isn't signed by
the Fulcio root CA during the signing workflow?
- Does the client fail when given an invalid inclusion proof from Rekor during
the verification workflow?
- Does the client fail when given an invalid signed certificate timestamp as
part of the Fulcio response in the signing workflow?
- etc
An official Sigstore client specification is being worked on at the moment as
part of the [Sigstore Architecture Documentation](https://github.com/sigstore/architecture-docs).
Once it's complete, `sigstore-conformance` aims to be able to test a client's
adherence to the specification.
Some general testing principles for this suite are:
- *Tests should be "workflow" focused.* This testing suite is not about fuzzing
every possible input to the client CLI or achieving code coverage.
- *Tests should exercise the entire client end-to-end rather than individual
subsystems in isolation.* Tests should include all network interactions with
Sigstore infrastructure such as Rekor, Fulcio, etc. These tests should run
against Sigstore staging and production infrastructure as well as custom built
mock services to test atypical scenarios.
- *Most verification tests can be parametrized without new code.* See
[test/assets/bundle-verify/README](test/assets/bundle-verify/README.md)
## Usage
1. Include an executable in your project that implements the
client-under-test [CLI protocol](docs/cli_protocol.md).
2. Use the `sigstore/sigstore-conformance` action in your test workflow:
```yaml
jobs:
conformance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# insert your client installation steps here
# Run tests against production Sigstore environment
- uses: sigstore/sigstore-conformance@v0.0.25
with:
entrypoint: my-conformance-client
# Run tests against staging Sigstore environment
- uses: sigstore/sigstore-conformance@v0.0.25
with:
entrypoint: my-conformance-client
environment: staging
```
See [selftest workflow](https://github.com/sigstore/sigstore-python/blob/main/.github/workflows/conformance.yml)
for a complete example.
### `sigstore/sigstore-conformance` action inputs
The important action inputs are
* `entrypoint`: required string. A command that implements the client-under-test
[CLI protocol](docs/cli_protocol.md)
* `environment`: 'production' (default) or 'staging'. This selects the Sigstore environment to
run against
* `xfail`: optional string. Whitespace separated test names that are expected to fail. Shell style
wild-cards can be used (e.g. `test_verify*intoto*`). Note that "[" used in some test names is
a wild card character that can be matched with e.g. "[[]".
See [action.yml](action.yml) for full list of inputs.
### Configuring `xfail` for optional tests
[[example]](https://github.com/sigstore/sigstore-conformance/blob/eae6eb1f59e25c6d3d602c5dad3dc55767c2f1cb/.github/workflows/conformance.yml#L44)
Depending on a client's optional feature support, the following test patterns can be added to the `xfail` config
- `test_verify*intoto*`: Older, deprecated intoto types that can be ignored for new clients.
- `test_verify*managed-key-happy-path]`, `test_verify*managed-key-and-trusted-root]`: Tests that require clients to support managed keys
## Development
Easiest way to run the conformance suite locally is with the provided virtual environment:
```sh
$ make dev
$ source env/bin/activate
(env) $
```
The test suite can be configured with
* `--entrypoint=$SIGSTORE_CLIENT` where SIGSTORE_CLIENT is path to a script that implements the
[CLI specification](https://github.com/sigstore/sigstore-conformance/blob/main/docs/cli_protocol.md)
* optional `--staging`: This instructs the test suite to run against Sigstore staging infrastructure
* optional `--skip-signing`: Runs verification tests only
* The environment variable `GHA_SIGSTORE_CONFORMANCE_XFAIL` can be used to
set expected failures
```sh
(env) $ # run all tests
(env) $ pytest -v --entrypoint=$SIGSTORE_CLIENT
(env) $ # run verification tests only
(env) $ pytest -v --entrypoint=$SIGSTORE_CLIENT --skip-signing
```
Following example runs the test suite with the included selftest client script:
```sh
(env) $ # run all tests
(env) $ GHA_SIGSTORE_CONFORMANCE_XFAIL="test_verify*-intoto-with-custom-trust-root] test_verify*managed-key-happy-path] test_verify*managed-key-and-trusted-root]" \
pytest -v --entrypoint=selftest-client
...
(env) $ # run single test
(env) $ pytest -v --entrypoint=selftest-client -k test_verify[DIGEST-happy-path]
...
```
## Licensing
`sigstore-conformance` is licensed under the Apache 2.0 License.
## Code of Conduct
Everyone interacting with this project is expected to follow the
[sigstore Code of Conduct](https://github.com/sigstore/.github/blob/main/CODE_OF_CONDUCT.md)
## Security
Should you discover any security issues, please refer to sigstore's [security
process](https://github.com/sigstore/.github/blob/main/SECURITY.md).