Fold release and disclosure lessons into the release and security skills

skills/roller-release/SKILL.md

@@ -78,8 +78,9 @@ the website points to the new release and archive availability is confirmed.
 Keep historical signing keys available for verification of old releases.
 
 For security releases, coordinate advisory timing with the PMC and ASF Security;
-use the companion `roller-security` skill when available. Public vote material
-must not expose undisclosed case details. The operator upgrade must be available
+use the companion `roller-security` skill when available. Public vote material,
+announcements and release notes must not expose undisclosed case details; keep
+them neutral until the advisories are out. The operator upgrade must be available
 when the advisory is published.
 
 ## References and helpers

skills/roller-release/references/dist-svn.md

@@ -38,16 +38,21 @@ accessible even though it is not an official release; do not upload private note
 
 Record the passed vote, source SVN revision, candidate filenames and destination.
 Use an SVN working copy or a single reviewed repository transaction to promote
-only that candidate. Preserve archive bytes and detached signatures. If removing
-an RC suffix from filenames, update the filename references in checksum sidecars
-and verify each digest against the unchanged archive.
+only that candidate. A sparse working copy of the repository root lets one commit
+`svn mv` each file from dev to release, renaming it as it goes. Preserve archive
+bytes and detached signatures. If removing an RC suffix from filenames, update
+the filename references in checksum sidecars and verify each digest against the
+unchanged archive.
 
 Do not blindly promote everything in a version directory: it may contain cancelled
 candidates or unrelated files. Verify the final inventory, signature fingerprints
 and checksum checks after promotion. Never rebuild to remove an RC suffix.
 
 Wait for distribution propagation and check the public download URLs, not merely
-SVN success. Follow the current
+SVN success. downloads.apache.org redirects missing files to the archive, so a
+request that does not follow redirects can report success for a file that is not
+there; check the directory listing or follow redirects to the final response.
+Follow the current
 [release publishing guidance](https://infra.apache.org/release-publishing.html)
 for timing. Update the website and verify its links before announcing.
 

skills/roller-release/references/vote-and-announce.md

@@ -74,3 +74,14 @@ Release notes: [public URL]
 
 Check the current ASF and project announcement guidance for recipients and
 formatting. Tally binding votes by PMC membership; do not count every +1 as binding.
+Check membership against the ASF roster (for example the public LDAP projects data),
+not the project website's committer list, which can lag.
+
+Send the announcement from your `@apache.org` address; announce@apache.org rejects
+other senders without warning. Confirm it in the announce@ archive.
+
+When a release carries undisclosed security fixes, keep the announcement, release
+notes, blog posts and website neutral until the advisories are sent: describe
+behaviour changes and upgrade guidance without characterizing the fixes.
+Instructions given to anyone writing that text must not reveal what is being
+withheld.

skills/roller-release/references/website.md

@@ -33,6 +33,15 @@ and KEYS from the official distribution site rather than an arbitrary mirror.
 Verify versioned archive links and all verification sidecars after propagation.
 A redirect response alone is not evidence that its destination archive exists.
 
+Fetch and rebase onto the remote publishing branch before pushing, and regenerate
+`content/` afterwards; do not overwrite other people's site changes. Preview by
+serving `content/` as the web root, since the templates use absolute paths. Check
+the rendered HTML as well as the source: Markdown features such as tables may not
+be enabled, and inline HTML is the safer choice.
+
+A project security page must not list or hint at undisclosed CVEs. Link CVE records
+only once they are published.
+
 Publish the website only when the approved release artifacts are available.
 Verify the live page and links before announcement, then prune superseded
 releases within the agreed scope. Keep release-specific website defects in the

skills/roller-security/SKILL.md

@@ -43,6 +43,12 @@ is safe: review what the entire change reveals, including related cases. Resolve
 uncertainty with the PMC and ASF Security. Do not assume that derivability from
 public source makes an unannounced finding appropriate for publication.
 
+When public text such as a release announcement, blog post or website page is
+prepared before disclosure, by a person or another agent, give the author the
+permitted facts and the constraints on scope and tone. Do not tell them what is
+being withheld or why: the instruction itself must be safe to leak. Keep such text
+neutral until the advisories are out.
+
 Keep only generic procedures and synthetic templates in this skill. Do not add
 live portal screenshots, case-derived examples, or release execution notes.
 
@@ -51,7 +57,9 @@ live portal screenshots, case-derived examples, or release execution notes.
 1. Locate the private workspace and read its summary and the item's `TRACKING.md`.
 2. Read the original report, reproduction evidence and `IMPLEMENTATION.md`.
 3. Check the implementation branch, review state and release target against the
-   actual repository. Do not infer that a message was sent from a draft file.
+   actual repository. Do not infer that a message was sent from a draft file, or
+   that none was received because the record lacks one; search the correspondence
+   before stating what a reporter said or did not say.
 4. Reconcile `CVE_FORM.md` before using the portal or drafting an advisory.
 
 For new cases, copy `assets/item-template/` into a private item directory.
@@ -89,13 +97,20 @@ project-specific decisions. Verify current policy when performing the workflow.
    that regression tests detect the reported behavior and pass with the fix;
    keep sensitive reproduction evidence private. Use the target branch's
    supported JDK and documented test commands, not a machine-specific SDK path.
+   Record as `fix_commit` the commit that landed on the release branch (the merge
+   or squash commit), not the pull request's branch head, and confirm it is an
+   ancestor of the release tag before citing it in a CVE record.
 7. Give the reporter the fix and draft advisory for comment with a reasonable
    deadline. Coordinate merge timing with the PMC; the ASF default places
    reporter review before commit. Record any agreed project variation.
 8. Release the approved fix. The companion `roller-release` skill covers the
    mechanics when available; otherwise use the project's release documentation.
 9. Coordinate disclosure with release availability, verify announcement recipients,
    update public security information, and add announcement references to the CVE.
+   Confirm each advisory in every list archive rather than assuming delivery,
+   and notify reporters separately with their advisory links, since the list
+   emails do not reach them. Log each reporter reply in the case record when it
+   arrives.
    Do not rewrite pushed Git commits to add CVE IDs.
 
 ## Multiple reports

skills/roller-security/assets/item-template/TRACKING.md

@@ -29,7 +29,7 @@ cvss_score:
 # External identifiers and implementation artifacts
 cve:                         # CVE-YYYY-NNNNN
 branch:                      # name the change, never the flaw
-fix_commit:
+fix_commit:                  # merge/squash commit on the release branch, not PR head
 tests: []
 target_release:
 credit: >-

skills/roller-security/references/comms-templates.md

@@ -86,3 +86,31 @@ Use the portal-generated advisory and review its fields before sending:
 
 Do not include private correspondence, internal record links, or reproduction
 steps by default. Coordinate recipients and timing with the ASF process.
+
+## Disclosure notice to reporter
+
+Subject: Apache Roller [version]: advisories published for your reports
+
+Apache Roller [version] was released on [date], and the advisories for the
+reports you sent us are now public:
+
+[CVE identifier]: [public title]
+  [public advisory link]
+
+[For duplicates: Your reports that duplicated earlier findings are credited on
+these advisories as well: ...]
+
+You are credited as "[approved wording]". Thank you for reporting these issues
+and for keeping them confidential while we prepared the fix.
+
+[Name, on behalf of the Apache Roller project]
+
+## Sending
+
+- Send ASF list mail from your `@apache.org` address. announce@apache.org rejects
+  other senders, while the other recipients still receive the message, so a failed
+  send is easy to miss.
+- Drafts created through mail APIs or automation can store links rewritten as
+  redirects. Check the raw message source before sending, or compose in the mail
+  client itself.
+- After sending, confirm the message in the list archive.

skills/roller-security/references/cve-portal.md

@@ -40,6 +40,32 @@ this skill intentionally contains no live screenshots or copied CVE records.
    publication state. Verify the current lifecycle controls and the agreed
    release/disclosure timing before either action.
 
+## Before READY
+
+Audit the generated JSON of every record, not only the editor view:
+
+- Metrics: only the agreed rating and vectors. Remove calculator defaults or
+  metrics in a CVSS version nobody assessed; an untouched default can score far
+  higher than the agreed severity.
+- Affected product: the default status must not be `unaffected` unless every
+  other version was actually assessed; otherwise use `unknown`.
+- Private metadata the portal uses in generated emails, such as the project URL,
+  is present. Render the email preview and read it.
+- References name the shipped fix, not a pull request branch head.
+
+Editors can reorder JSON keys on save. When checking what a save changed, compare
+content, not serialized text.
+
+## Publication sequence
+
+Follow the portal's current instructions. At the time of writing they are:
+
+1. Set READY once the fix is publicly available.
+2. Send the advisory emails from the record's email view. Confirm each one in every
+   list archive, including oss-security, which may not bounce a failed send.
+3. Add the public announcement as a `vendor-advisory` reference.
+4. ASF Security submits the record and sets PUBLIC. Do not set PUBLIC yourself.
+
 A generated JSON state is not proof that a CVE has been publicly announced.
 Private comments and references must remain outside public record fields and
 email bodies. Inspect actual To/Cc/Bcc recipients; do not rely on remembered