I don't mind having a mechanism to potentially deal with security issues in Attic projects.
I think we would need to be careful to keep expectations low that the mechanism would only be used in certain circumstances. A lot of Attic projects have a large number of known security issues or a backlog of issues that are known but unreported. In some cases, we are better off letting the project rest in peace. I fear that if we are not careful that we will get bounty hunters swarming all over long dead code bases. We could even be gaslit into letting people take over Attic projects by raising fears of security issues, only for them to act in bad faith if we let them make new releases of that project with Apache branding. On Thu, 10 Oct 2024 at 17:11, Mark Thomas <ma...@apache.org> wrote: > > On 10/10/2024 09:27, Gilles Sadowski wrote: > > Le jeu. 10 oct. 2024 à 17:12, Mark Thomas <ma...@apache.org> a écrit : > >> > >> All, > >> > >> One of the discussions during the security table top exercise in Denver > >> was how to handle the situation when we receive a security vulnerability > >> report in a project that is almost in the attic or has already entered > >> the attic. > >> > >> Can we simply respond "Tough. The project is EOL. You should not be > >> using it."? > >> > >> Or can we/ should we provide some sort of mechanism where those users > >> that still rely on the EOL product can come together, bring it out of > >> the attic, fix the vulnerability, release the fixed version and put it > >> back in the attic? > > > > That seems a nice thing to allow, but doesn't it break the > > ASF rules? [Namely that a release must be approved by > > at least 3 PMC members.] > > Yes, it would need to be under a PMC. > > We could move it out of the attic and under a suitable PMC. Could be the > attic, could be an appropriate existing PMC, could be some new PMC. > > How about "Apache Problematic" for the name if we use a new PMC? Sorry > in joke from the TTX - we needed a name for the project with the > vulnerability in the exercise and we settled on that. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: security-discuss-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
