rsonpath

All versions are available on crates.io https://crates.io/crates/rsonpath, and as releases on GitHub https://github.com/V0ldek/rsonpath/releases. Breaking changes are documented and included in the changelog for all releases.

GitHub Issues as tracker: https://github.com/rsonquery/rsonpath/issues

https://github.com/V0ldek/rsonpath/security/advisories

https://github.com/V0ldek/rsonpath/blob/main/CONTRIBUTING.md#guidelines

The CI automatically enforces formatting and clippy linting: https://github.com/V0ldek/rsonpath/actions/workflows/rust.yml

The build system used is the standard Rust toolchain (cargo) which honors flags and passes them down to rustc.

Debugging information is enabled by default even in release builds: https://github.com/V0ldek/rsonpath/blob/e04675f782fb7408089dbe5ea41f03ecb44c5eca/Cargo.toml#L21; this can be overriden when building with cargo.

The project hierarchy is flat and has no cross-dependencies; cargo builds all direct workflow targets; dependencies are pinned with Cargo.lock.

The CI pipeline is reproducible: https://github.com/V0ldek/rsonpath/actions/workflows/rust.yml; releases include strong provenance data following SLSA3: https://github.com/V0ldek/rsonpath/actions/workflows/release.yml, https://slsa.dev/spec/v1.0/about

Software can be installed with cargo install: https://github.com/V0ldek/rsonpath#installation

The cargo install command honors the --root argument for the target directory.

Local development uses standard tools and is documented in the contribution file: https://github.com/V0ldek/rsonpath/blob/main/CONTRIBUTING.md#setting-up-local-development; common development operations are scripted with a command-runner (just): https://github.com/V0ldek/rsonpath/blob/main/Justfile

All dependencies are listed in standard Cargo.lock: https://github.com/V0ldek/rsonpath/blob/main/Cargo.lock

Repository is monitored with Dependabot; before each release the cargo update command is ran.

Dependencies are managed in the standard manner for Rust projects, and all dependencies are clearly described as to what their importance in the project is in the README: https://github.com/V0ldek/rsonpath#dependencies

Deprecated and obsolete parts of the standard library raise warnings in the build pipeline, which are treated as errors; direct external dependencies are manually vetted to ensure they are maintained.

The Rust CI pipeline runs all tests on each PR: https://github.com/V0ldek/rsonpath/actions/workflows/rust.yml

This is explicitly mentioned in the Pull Request creation checklist.

The CI treats warnings as errors, a large number of additional lints is enabled for the project: https://github.com/rsonquery/rsonpath/blob/main/crates/rsonpath-lib/src/lib.rs

The project has no access management. Potentially unsafe operations are implemented with standard design principles in mind: SIMD operations are properly guarded with appropriate target_feature flags; the one place where manual memory management is required is tested, follows standard design practices for similar Rust applications, and can be verified with SAFETY documentation: https://github.com/V0ldek/rsonpath/blob/main/crates/rsonpath-lib/src/input/owned.rs

No functionality depends on cryptography.

All releases have signed provenance (SLSA level 3). Verifying provenance is described in the book: https://v0ldek.github.io/rsonpath/user/installation.html#verifying-provenance

Part of signed provenance (SLSA level 3) is cryptographically verifying that the release was produced from a specific version tag.

The inputs always come from the user of the binary.

We enable a lot of optional clippy flags, for vulnerabilities the most important is undocumented_unsafe_blocks which requires explicit analysis and review of unsafe code: https://github.com/rsonquery/rsonpath/blob/main/crates/rsonpath-lib/src/lib.rs#L178

Each PR is fuzzed with libfuzzer, and longer fuzzing is ran on a schedule every day.