add pre-flight validation that security_list is configured, with fallback to security@apache.org

[justinmclean]

Summary

The ASF security_committers policy (https://www.apache.org/security/committers.html) states:
If the project does not have a dedicated security@project.apache.org mailing list, all further communication regarding the vulnerability should be copied to security@apache.org.

The project template (projects/_template/project.md) already has security_list as a required TODO field and asf_security_list: security@apache.org hardcoded as the ASF-wide fallback. However, no skill validates that security_list is actually set to a non-blank value before running, and no skill falls back to asf_security_list if it is blank. If an adopter leaves security_list empty, every Gmail draft generated by the skills will silently have a blank CC field, violating the ASF policy CC requirement without a warning.

Affected skills

security-issue-sync, security-issue-invalidate, security-issue-import, security-cve-allocate — any skill that produces outbound Gmail drafts.

Required changes

In security-issue-sync Step 0 pre-flight, add a check that reads security_list from /project.md. If blank or missing, surface a hard warning and record cc_fallback: security@apache.org in the observed-state bag. In every Gmail draft template across all affected skills, resolve the CC recipient to security_list if non-blank; otherwise, to asf_security_list.

Add a note to docs/setup/adopter-config.MD documenting the blank-security_list behavior and why configuring it correctly matters.

Policy reference

https://www.apache.org/security/committers.html — "Project-specific security mailing lists" and "Report" sections

[andreahlert]

@potiuk happy to take this one, but the four files it touches are all yours (asf-relay.md entirely), so wanted to check the approach before I start.

The issue says resolve the CC in every Gmail draft template across all affected skills. that means copying the same fallback logic into 4 skills.

I'd rather fold it into the placeholder in tools/gmail/operations.md instead, so it resolves to security_list when set and asf_security_list otherwise, and the skills inherit it for free.

You designed that placeholder convention so wanted your call onit.

Also docs/setup/adopter-config.MD from the issue doesn't exist. closest thing is docs/setup/README.md. should the blank-security_list note go there?

If the centralized approach works for you I'll pick it up.

[justinmclean]

@andreahlert are you still working on this?

[andreahlert]

I'm back! I've picked this up again and opened PR #1200 for your review.

The implementation centralizes security CC resolution in the shared mail-source contract. It warns and uses the configured fallback when the project security list is missing, and blocks draft creation if neither address is available. Mailbox searches keep their existing behavior.

I've also added configuration evals and regression tests for the OAuth and MCP draft recipes.

@potiuk @justinmclean, I'd appreciate your feedback on the approach!

[potiuk]

Just wait a "bit" - I am finalizing installation and adoption with marketplace - work in progress - that I hope to have finished today.