Dear Polaris community, I would like to ask for a discussion on whether we need clearer guardrails for security-sensitive changes.
The topic already came up in PMC discussion and the feedback there was to discuss the guardrails question on dev@. I think the project would benefit from clearer guardrails for security-sensitive changes, especially where changes touch authorization, credential vending, storage boundaries, secret handling, or similar areas. For that reason, I think it makes sense for the community to agree on a small set of guardrails for such changes. I would like the community to discuss and ideally adopt guardrails along these lines: * if a PR expands capability in one of these areas, it should not merge while the boundary/authz/validation part that makes it safe is still deferred to follow-up work, * off-list discussion may inform a design discussion, but it should not be presented as if it already settled an on-list project decision, * "beta", "experimental" and "off by default" do not lower the security or design-review bar for shipped code, * risky or immature features should not be described in release notes or docs as production-ready before their actual limitations are resolved, * risky changes in these areas should include a review that explicitly checks the mandatory safety properties, and * if a subsystem already has open security or boundary debt, additional feature expansion there should be approached conservatively until the key invariants are clarified and tested. My ask is simply about whether guardrails of this kind are needed, and if so, which ones we want to adopt. If there is agreement on this, we can simply refer to it in future reviews instead of arguing the same point repeatedly. I would appreciate your feedback on whether the project wants guardrails of this kind, and if yes, which ones. Robert
