On Tue, Dec 21, 2021 at 4:19 AM Mads Toftum <[email protected]> wrote: > On Tue, Dec 21, 2021 at 10:54:08AM +0000, Mark Thomas wrote: > > On 21/12/2021 09:35, Hen wrote: > > > > The inactive projects will have been moved to the attic. A bigger > > issue - in my view - is the projects that are on the cusp of moving > > to the attic. They have enough activity to move forward just enough > > to avoid the attic but not enough to react to a security issue. > > There are projects that have vulnerabilities that have remained > > unaddressed for far too long. > > > > Too long is subjective and will vary by circumstance but I think > > there comes a point when a project's failure to make meaningful > > progress to address a security issue in a reasonable time frame > > should result in the project being moved to the attic. > > > Perhaps missing responses on security issues could be used as a > first indication that a move to attic should be discussed? >
I obviously like the idea, but I've a scythe and hood in a cupboard somewhere. > > > >It's a hard one to fix, assuming it should be fixed. Personally I think > > >there should be some kind of alert when a project moves to the Attic. > > Right now there's an email going to a projects list as part of the attic > process. https://attic.apache.org/process.html > > > > There should be an email to announce@. > > > I think that would be simple enough to roll into the attic process. > I was thinking of something more like the CVE process. I see a lot of focus in the industry/community over project health, but we don't even have a common way to identify dead-parrots. What I'd love to do as a user who is a bear of large size is to ingest a stream of events that equate to "This project is no more. It has ceased to be.". That may be too pat though. Building/buying algorithms that determine likelihood of a release happening if needed may be the only way to go. We'll probably never get to a place where folk are turning the lights off across popular open source as a whole. > > > Email to all PMCs would likely be noise for most PMCs and targetting > > an email would require knowledge of dependencies. > > > Agreed. > +1. I'm thinking of user pull rather than push to PMCs. > > > Generally, I'd expect projects to be reviewing their dependencies > > fairly regularly. > > > Do we or could we have build tools that report on this? > Dependabot-on-GitHub wise, there is a dashboard but presumably only visible to the organization owners. The new Repository roles maybe could be used to create a Security role who can see it for all repos without making the Security Team Owners on the organization. Can also write GH API code to pull the data; though doing it as a GH Action is probably better if we're hitting the 5,000 PAT limits. Hen
