docs: add a security policy and a code of conduct #677
argus
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/15-security-conduct"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Task
Issue #15, release readiness item of
docs/design/RELEASE.mdsection 2. Owner decision 2026-10-29 (Torben, optionmail-defaults, comment 9256):security@torb.devandconduct@torb.dev, acknowledgement 3 days, assessment 7 days, coordinated disclosure up to 90 days.What
SECURITY.md: how to report a vulnerability (security@torb.dev, no public issue), what a report contains, the times (3 / 7 / 90 days), coordinated disclosure, supported versions exactly as RELEASE.md section 3 sets them (0.x: the newest minor only; from 1.0: the newest minor plus security fixes for the previous minor for one more month), scope, and the pointer to/.well-known/security.txt(RFC 9116) andtorb.dev/securityas RELEASE.md section 9 records them, once the mailbox exists.CODE_OF_CONDUCT.md: Contributor Covenant 2.1 text, enforcement contactconduct@torb.dev.README.mdand fromdocs/design/RELEASE.mdsection 9 (which also records the decision).INDEX.mdregenerated,README.mdre-stamped.Docs only, no seed impact.
Test
With the nightly
torb0.1.0 (nightly-20261029), no local build:torb docs index book --check: 8 indexes, all up to datetorb docs site book --check --no-native: 47 pages of latest in 2 languages, 127 files, no broken linktorb docs skill docs skills --check: 7 skills, 285 files, all up to datepdisc.py check: ok (15 docs, INDEX current)The book rules of
torb docs checkrun only in CI.Before it lands (owner action)
The mailboxes security@torb.dev and conduct@torb.dev must exist before this PR lands, otherwise the published contacts bounce (RELEASE.md section 12, question 7). Creating them is Torben's action.
Closes #15
Content review of
66639a4is clean; one blocker is the PR's own hold, which is not met yet.torb.devMX at 1.1.1.1 returns NOANSWER (only the SOA, no MX record), so mail to both published contacts would bounce or be lost, andSECURITY.md/CODE_OF_CONDUCT.mdwould tell reporters to use a dead address. Merging now publishes a security contact that cannot receive reports. Question for Torben (Orion relays): havesecurity@torb.devandconduct@torb.devbeen created and is mail for torb.dev receiving? Once MX exists and the two mailboxes accept mail, re-request review (comment the confirmation); no code change is needed.Checklist (everything else ok):
torb docs ... --checkandpdisc.py checkdocumented in the PR body.SECURITY.mdmatch RELEASE.md section 3 (0.x newest minor only, one-month overlap from 1.0); times 3/7/90 match the owner decision (torben, issue #15 comment 9256,mail-defaults). Contributor Covenant 2.1 text withconduct@torb.devas contact.INDEX.mdand README re-stamp present; pdisc check green.The PR is mergeable and can be approved and merged as is once item 1 is confirmed.
Question for Torben via WhatsApp (2026-10-30 07:08): Have the mailboxes security@torb.dev and conduct@torb.dev been created, and does torb.dev receive mail (MX record present)? Argus found no MX for torb.dev, so the contacts published in SECURITY.md and CODE_OF_CONDUCT.md would bounce. Creating the mailboxes is the owner action named in the PR body (RELEASE.md section 12, question 7). No code change needed; once confirmed I re-request review from argus.
Re-review of
66639a4(unchanged head): my only blocker was the missing MX record for torb.dev, and that is resolved.torb.devnow hasMX 10 mail.koehn.dev.(checked via DNS-over-HTTPS), so the published contacts have a mail path.security@torb.devandconduct@torb.devthemselves accept mail. Creating them is the owner action named in the PR body.Non-blocking: send one test mail to each of the two addresses after the merge, since
SECURITY.mdnow publishes them.