When a software product is no longer maintained, it is important for downstream users to be aware of this fact. At the ASF, we do this by retiring the project to the Attic.

Mere low activity alone does not necessitate a move to the attic: some projects have simply entered a phase in their lifecycle where few changes or releases expected, while there is still a community around to come into action if necessary.

However, when there is no longer a community that can responsibly deal with (potential) security issues found in the project, that may make the move to the Attic inevitable. Ideally, the project's Project Management Committee (PMC) would make this decision themselves. In rare cases, the project has become so inactive that the PMC can no longer make the decision to move the project to the Attic. In that case, the Security Team initiates this process. This is taken lightly: it is the last step in a process where the project has received numerous reminders on their private lists, a call for help on their public lists, and a security roll call. The more formal escalation steps in this process are documented at Project Security Response Formal Escalation.

This page documents the more 'bureaucratic' steps needed to execute the final step of that escalation process.

• For any plausible open security reports:
  
  • allocate a CVE
  • populate it, including adding the 'unsupported-when-assigned' tag
  • share the proposed advisory on the project's private and/or security lists
• Create an Attic Jira item as described at https://attic.apache.org/process.html. Note that no board resolution is needed in this case: the board should be aware of the projects' issues (for example through the Security Roll Call and the monthly board reports of the Security Team), and being a 'Board Committee' the Security Team can make this decision on its own.
• When the move to the attic is publicly announced, also publish any advisories for outstanding security reports.