Story (Required)

As a security-conscious administrator trying to secure the build system, I want the /ok-to-test memory feature to be disabled by default after a migration period, so that external contributors cannot exploit it to push malicious changes targeting the build system, while ensuring a smooth transition for existing installations.

Background (Required)

Currently, when /ok-to-test is remembered, an external contributor can gain trust with a reasonable code change and then push a malicious change aimed at the build system (e.g., secret exfiltration). This poses a significant security risk. To mitigate this, PAC should:
1. Announce a migration period during which /ok-to-test memory will remain enabled by default.
2. After the migration period, disable /ok-to-test memory by default.
3. Provide clear documentation about the risks and require installations to explicitly opt-in to enable this feature, accepting the associated risks.

Out of scope

• Modifying the behavior of /ok-to-test itself.
• Implementing additional security measures beyond disabling the memory feature by default.

Approach (Required)

• Announce a migration period (e.g., 3 months) during which /ok-to-test memory remains enabled by default.
• After the migration period, update PAC to set /ok-to-test memory to false by default.
• Add documentation highlighting the risks of enabling /ok-to-test memory and the migration timeline.
• Allow installations to explicitly enable /ok-to-test memory via configuration.
• Notify existing installations of the upcoming change and provide guidance for migration.

Dependencies

• None identified at this time.

Acceptance Criteria (Mandatory)

• A migration period is announced and documented.
• After the migration period, /ok-to-test memory is disabled by default in PAC.
• Documentation is updated to clearly explain the risks of enabling /ok-to-test memory and the migration process.
• Installations can explicitly enable /ok-to-test memory via configuration.
• Existing installations are notified of the change and provided with migration guidance.

INVEST Checklist

• Dependencies identified: None
• Blockers noted: None
• Design is implementable: Yes
• Acceptance criteria agreed upon: Pending
• Story estimated: Pending

Done Checklist

• Code is completed, reviewed, documented, and checked in.
• Unit and integration test automation delivered and running cleanly.
• Continuous Delivery pipeline(s) can proceed with new code.
• Customer-facing documentation is updated and published.
• Acceptance criteria are met.