cribra 0.3.0

Privacy-first Rust core for detecting, querying, and safely transforming secrets and sensitive data
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

# CI/CD

Cribra treats `main` as the release-quality branch.

## Continuous integration

Pull requests and pushes to `main` are validated by four independent surfaces.

### CI

The primary Linux gate runs:

```text
cargo fmt --all -- --check
cargo check --all-features
cargo test
cargo test --features serde
cargo test --all-features
cargo test --doc
cargo clippy --all-targets --all-features -- -D warnings
cargo package --allow-dirty
```

macOS and Windows additionally run cross-platform `cargo check` and test gates.

### MSRV

`Cargo.toml` declares Rust 1.97 as the minimum supported Rust version.
The MSRV workflow tests that contract explicitly rather than relying on the
stable toolchain.

### WASM

The supported browser-oriented WASM contract is checked for
`wasm32-unknown-unknown` with:

- default features;
- `serde`.

The optional `parallel` feature is not part of the supported browser WASM
contract.

### Security

RustSec's `audit-check` action audits `Cargo.lock`:

- when dependency manifests change;
- on pushes to `main` that modify dependencies;
- every Monday;
- on explicit manual dispatch.

Scheduled audits may create GitHub issues for newly discovered advisories.

Dependabot checks Cargo and GitHub Actions dependencies weekly.

## Release process

Releases are tag-driven.

A tag such as:

```text
v0.2.0
```

must exactly match the version in `Cargo.toml`.

The release workflow then:

1. validates the tag/version match;
2. runs formatting, checks, tests, rustdoc and clippy;
3. runs `cargo package`;
4. runs `cargo publish --dry-run`;
5. authenticates to crates.io using Trusted Publishing/OIDC;
6. publishes the crate;
7. creates the matching GitHub Release.

No release is published from an ordinary push to `main`.

## crates.io Trusted Publishing bootstrap

Trusted Publishing requires the crate to exist on crates.io before the trusted
publisher can be configured.

For the first `cribra` release:

1. publish the initial Cribra crate manually;
2. configure `Metalymph/cribra` as a trusted GitHub publisher on crates.io;
3. configure the GitHub `release` environment if desired;
4. use tag-driven releases from that point onward.

No long-lived crates.io API token is required by the automated release
workflow.

## Recommended branch protection

For `main`:

- require pull requests before merge;
- require the CI, MSRV, WASM and Security status checks;
- require branches to be up to date before merge;
- require conversation resolution;
- block force pushes;
- block branch deletion.

While Cribra has a single maintainer, review approval can remain optional.
When external contributors become active, require at least one approving
review.

## Local equivalent

Before pushing a substantial change, run:

```text
cargo fmt --all
cargo fmt --all -- --check
cargo check --all-features
cargo test
cargo test --features serde
cargo test --all-features
cargo test --doc
cargo clippy --all-targets --all-features -- -D warnings
cargo package --allow-dirty
```

Security audits can be run locally with:

```text
cargo install cargo-audit
cargo audit
```