Security policy
This policy covers the open monetize crates in this repository (monetize, monetize-server, monetize-pay, monetize-embed, the guest crates and the other monetize-* crates), the ONE box build (monetize-admin), and the hosted service at https://monetize.vetra.se. The payment and cloud vendors in the private monetize-impl follow the same policy.
Report a vulnerability privately
Write to gunnar@gunnar.rs. Start the subject line with SECURITY: monetize.
Do not open a public issue for a vulnerability, and do not push a proof of concept to a public repository. If you want an encrypted channel, say so in a short first mail without details, and we agree on one with you (for example an age key).
What to put in a report
- The commit, and the crate.
- The build: the default build, or the features you turned on (for example
sandbox,invoice, or the ONE box build). - How to reproduce it: the steps, the configuration, and a proof of concept if you have one.
- What an attacker gains, as you see it.
- Whether you plan to publish, and when.
- The name you want in the credit, or that you want none.
What happens next
- We acknowledge your report within 14 days.
- We tell you whether we accept it as a vulnerability, and we keep you informed while we work on it.
- Our target is a fix or a documented mitigation within 60 days of the report. For a critical vulnerability we aim for 14 days.
- We agree the publication date with you. By default we publish when the fix is released, and at the latest 90 days after the report.
- We credit you in the advisory, unless you ask us not to.
Supported versions
Only main and the release the ONE box runs get security fixes. A fix lands on main first.
Dependency advisories and updates
- cargo-deny reads every lock in this repository against the RustSec advisory database. An advisory fails unless
deny.tomlignores it, and every ignore there states its reason and the date it was triaged. An ignore is only for an advisory with no fixed release that we have checked cannot be reached in monetize, or that is not a vulnerability (an unmaintained compile-time crate). - The same triage is in the
osv-scanner.tomlbeside eachCargo.lock(read by OSV-Scanner and the OpenSSF Scorecard), each with anignoreUntildate that forces the next look;xtask/tests/osv_triage.rskeeps the two lists equal. renovate.jsondescribes the update policy: the Cargo locks, the browser image and the workflow actions, proposed weekly, advisories at once, images and actions pinned by digest. No Renovate bot runs on gunnar.rs: the dwarves forge runs a weekly dependency-update job that proposescargo updateas a new branch after the quick CI went green on it, and a person merges it.fuzz/holds cargo-fuzz targets for the parsers that read untrusted bytes (vendor callbacks, the feed andmonetize.toml, signed facts, the Fleet door, a box's orders); the forge runs them every night.