chore: explicitly scope contracts/asserter-consumer in SECURITY.md - #136
Conversation
SECURITY.md's Scope section only said 'the contracts under contracts/' without naming asserter-consumer specifically, even though it calls out demo-consumer by name as out of scope. A reader skimming the doc had no way to tell whether asserter-consumer was deliberately in scope or just forgotten. Explicitly list contracts/tholos, contracts/tholos-v2, and contracts/asserter-consumer as in scope, per the issue's proposed wording. Closes drydocs#122
|
Done! I finished the SECURITY.md scope clarification task (#122). Explicitly listed contracts/tholos, contracts/tholos-v2, and contracts/asserter-consumer as in-scope, following the wording proposed in the issue. |
| `contracts/demo-consumer` example, which exists to validate integration patterns | ||
| and is not intended for production use on its own. | ||
| In scope: the contracts under `contracts/` in this repository, including | ||
| `contracts/tholos`, `contracts/tholos-v2`, and `contracts/asserter-consumer`. |
There was a problem hiding this comment.
contracts/asserter-consumer's own doc comment (src/lib.rs:3-6) and CONTRIBUTING.md's project-layout table both describe it as an integration example in the same category as demo-consumer, which this same sentence excludes as a non-production example. Declaring it in scope here contradicts the contract's own stated purpose. Either scope it in with a rationale for why it differs from demo-consumer, or leave it excluded.
There was a problem hiding this comment.
Ready to merge from my end — 5d3e3a8 addresses the scope contradiction you flagged. asserter-consumer stays in scope, but I added an explicit rationale distinguishing it from demo-consumer: it demonstrates authorize_as_current_contract, where the contract self-authorizes a fund transfer with no human signer in the loop — a pattern real integrators are expected to copy into production. demo-consumer's end-user-signs-directly pattern has no comparable surface to get wrong, which is why it's still excluded. Let me know if you'd rather see it phrased differently or scoped out entirely instead.
collinsezedike
left a comment
collinsezedike
left a comment
There was a problem hiding this comment.
@Iker2522 thank you for the contribution. This looks good, there is nothing to flag.
collinsezedike
left a comment
collinsezedike
left a comment
There was a problem hiding this comment.
Thanks for this, clean fix, matches the issue exactly. Merging now.
If you're looking for more, there are several open issues without an assignee yet. If you have a moment, a star on the repo would be appreciated too.
2 participants
Closes #122
Summary
SECURITY.md's Scope section listed contract-inclusion as a blanket statement — "the contracts undercontracts/in this repository" — without naming any of them individually, while at the same time calling outcontracts/demo-consumerby name as explicitly out of scope. This asymmetry meant a reader skimming the document for what's covered had no reliable way to tell whethercontracts/asserter-consumerwas deliberately included under the blanket statement, or simply overlooked when the doc was written — especially since it sits directly alongsidedemo-consumerin thecontracts/directory, which the doc does name.Change
Updated the Scope section to explicitly list the in-scope contracts by name —
contracts/tholos,contracts/tholos-v2, andcontracts/asserter-consumer— rather than relying on an implicit blanket statement. The out-of-scope wording (third-party dependencies,contracts/demo-consumer) is unchanged, since that part of the doc was already unambiguous.This follows the wording proposed directly in the issue.
Diff
Only
SECURITY.mdis touched — a 4-line to 5-line wording change in the Scope section, no other files affected.Verification
contracts/asserter-consumerexists in the repository (ls contracts/) and is a real, buildable contract alongsidetholosandtholos-v2, not a stub or placeholder.