Repository navigation
docs: resolve the three open questions left in the patch policy - #20
Conversation
Scope: the monthly private repositories cover every repository in bug bounty scope. The named repositories were reading as the limit rather than as examples, so a team outside the list could not tell whether it was covered. Leaking patch source: passing it on before the patch is public costs a team access to the private repositories and any future invitations. The existing consequences ladder is written for reporters and turns on bounty eligibility, which means nothing to a downstream chain, so it left this rule unenforced on paper. Further action is left open pending the legal position on NDAs. Active exploitation: handled immediately and separately, rather than just "as an incident".
|
| A team that passes patch source on before the patch is public loses access to | ||
| the private repositories, including the invitations to any future ones. We may |
There was a problem hiding this comment.
Conflicting disclosure consequences A team that publishes patch source early for the first time falls under both this new rule, which removes current access and future invitations, and the later disclosure policy, which specifies a warning for a first instance. These conflicting outcomes leave teams and the security response team without a consistent enforcement policy. Clarify which rule takes precedence.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| inside a vendored dependency tree, and do not make it available to validators or | ||
| node operators. | ||
|
|
||
| A team that passes patch source on before the patch is public loses access to |
There was a problem hiding this comment.
Unclear boundary for sharing “Passes patch source on” does not say who must receive it for the access penalty to apply. The policy also permits teams to use the patch as needed to build and names specific prohibited destinations, so legitimate coordination with an authorized downstream team could appear to trigger the penalty. Distinguishing unauthorized disclosure from permitted private use would make the rule easier to follow and enforce.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
The access rule and the consequences ladder gave different answers for the same first offence. The ladder treats publishing something an attacker can act on immediately as a 3-month suspension; the access rule is permanent. They are not competing, because they are not the same kind of thing. The ladder penalises publishing vulnerability details ahead of a disclosure date, and its levers are bounty eligibility and list membership. Withdrawing access ends a grant that was conditional on the source staying private. Says so, so neither has to take precedence over the other. Also says who the source must not be passed to, since two teams that both have access coordinating on a fix were inside the old wording.
Drops a stranded "on" that pushed the subject three clauses from its verb, makes the cross-reference a real anchor link rather than a bare "below" that survives the docs sync as plain text, and fixes a loose antecedent in the scope sentence.
Scope now says every repository in bug bounty scope, with the named ones as examples rather than the limit.
Leaking patch source now costs access to the private repositories and any future invitations.