I'm in agreement with Phil here. And if there is a community comes together wanting to take over support of an Attic project (or even an EOL version of a non-Attic project) then we should totally encourage that inside of the ASF. This is totally a discussion to be having on the Attic PMC list.
Where it touches security are the things we've highlighted in the Brainstorm document. Firstly making sure we're absolutely clear to our users what is EOL and what isn't. Secondly on the policy for assigning CVE names to issues in EOL projects. This is harder, but in scope here. So let's say Apache Porcupine is in the Attic. We get a report of a security issue in it. But there might be no one left to determine if that issue is real or not and do the initial investigation. To prepare a CVE you really need to create reasonable quality information on versions affected, mitigations, severity, and so on. Around half the issues that are plausible-looking that get reported to ASF end up being non-issues (either bugs with no security consequence, or fixed in some later version already, or outside the threat model, or where the issue reporter didn't understand something). If you accept every report that comes in to an old project then it's still not zero cost to our security team, there's still work has to be done on every one. And, in the current climate, researchers want to collect CVE like Pokemon for their resumes, for their third party bug bounties, and so on, so if you allocate a CVE for every one I'd expect floods of low hanging low severity issues reported to us in decade-old projects. And vulnerability scanners rarely have metadata to report that versions they detect are EOL - so you really need at least one CVE name per EOL project just so companies get some notification that there are unfixed vulnerabilities. It's almost like you need one CVE for "is EOL and has unfixed vulnerabilities" perhaps even with a watermark "of highest severity X". I've been wondering how to solve this for a while for ASF. Rather than rejecting reporters with their EOL issues we could redirect them and have them post them somewhere public. That way anyone still using an EOL product (say a Linux distro shipping in an Enterprise product) could still hear about issues, assist in the investigation, help guide CVE issuance. Perhaps for Attic issues it's a public security list @attic. For EOL versions of non-Attic perhaps it's the dev list. That may also suit the researcher who will get the credit (and may be careful to make sure they post issues they've spent time looking at so they don't appear foolish in public), provides a public reference that can be used in a subsequent CVE request, etc. Regards, Mark J Cox ASF Security On Fri, Apr 8, 2022 at 7:33 AM Giovanni Bechis <[email protected]> wrote: > Absolutely agree here, we should list on our project's web pages > which version are EOL (like httpd and other projects already do) > and which one are supported in order to make it clear that we > cannot provide support for old releases and to make > users upgrade to more secure versions of our softwares. > > Giovanni > > On Thu, Apr 07, 2022 at 01:03:44PM -0700, Phil Steitz wrote: > > I don't think we should officially sanction anything that does not have a > > functioning ASF PMC behind it. Anyone can fork any of our current or > > retired projects at any time. A newly constituted PMC can also vote to > > revive code from the attic. All of that is already possible. I think we > > should actually go in the opposite direction - making end of life > > assertions earlier and more consistently. That is what commercial > software > > companies do and it makes it very clear what is supported and what is > not. > > As many of us have said publicly and we said collectively to the US > > government, it is the responsibility of system owners to upgrade or > replace > > end of life software in their systems. Giving false hope without an > active > > PMC is a bad idea, IMO which could backfire badly for both the ASF and > > downstream users. The fact is that all software eventually reaches end > of > > life and the responsible thing to do as a software producer is to make > end > > of life statements clearly and as early as possible. The idea of > > "afterlife" is like paying for extended support for end of life > commercial > > products - tends to end badly. > > > > Note that all of the above applies to "product lines" such as foo x.y. > The > > responsible thing to do, which Tomcat and others do well, is to announce > > EOL early and then retire the stuff that is no longer maintained. Again, > > this is exactly what commercial software companies do. Their decision is > > based on pretty much the same considerations as ours. There is no > > "afterlife." > > > > The Attic docs look clear and complete to me, including info on how to > fork > > / revive or include code in another project. > > > > Phil > > > > On Thu, Apr 7, 2022 at 8:07 AM Dirk-Willem van Gulik < > [email protected]> > > wrote: > > > > > We have the various conversations of what we can do better today with > > > regard to our vulnerability, release and supply-chain proceses. > > > > > > However, reading between de lines of the questions we get from the > various > > > powers that be - and their emphasis on societies/civic infrastructure > - I > > > think there is also a third area that we should tackle - what is the > > > afterlife of code. And for which we have little policy today. > > > > > > And that is for projects who are important to some; but have > insufficient > > > volunteer capacity at the ASF to be responsibly maintained and > released. > > > > > > I think that the setting / presumption here is (some of this we already > > > make explicit, some is implied but perhaps should be made explicit) is > that: > > > > > > 1) An Apache release 'you can get' has gone through the usual > > > processes and is `fit for purpose' and meets a set of standards. > > > > > > 2) One of these is that the (latest) download contains no known > > > vulnerabilities -- or if they contain known (minor) issues - such is > very > > > loudly called out in the release notes. > > > > > > If the ASF find that a project has losts it ability to maintain its > > > software responsibily (including responding to security issues; have > > > sufficient governance not dependent on one person, be under oversight > of > > > the board/report as they should) then we move that project to the Attic > > > > > > The Apache Attic was created in November 2008 to provide > process > > > and solutions to make it clear when an Apache project has reached its > end > > > of life. Specifically to be: > > > > > > "responsible for the oversight of projects which otherwise > would > > > not have oversight; and be it further ... is not authorized to actively > > > develop and release the projects under its oversight" > > > > > > (Quoting from https://attic.apache.org/). With a good set of trigger > > > rules. > > > > > > My proposal would be to add something extra here; namely the ability > for > > > any interested party to 'take over' an attic process on a non-exclusive > > > basis. And it is entirely up to that party to self-fund, find > volunteers, > > > etc, etc. So I think that just means a few extra process step and some > form > > > of policy. > > > > > > Firstly I would suggest we add two process steps - namely that the > > > community -and- our general apache announce list (and/or a new > legacy/attic > > > list) is to be informed pro-actively. > > > > > > Secondly - that we offer, for a period of 3 months, to bring any > > > interested party that contacts us in touch with any of the others if > they > > > so desire. > > > > > > And finally - that we offer a non-exclusive license to the name (but > > > without the apache prefix), trademark and full provenance/code > history; to > > > any party that wants to take over; provided they abide by the Apache > > > license. > > > > > > And that we will inform the existing community by our usual means > (email, > > > a long term URL/redirect/etc). And that we will maintain the key > > > provenance data behind the code base (CCLAs, iCLAS, identity of the > > > committers) -and/or furnish them with some sort of blanket transfer > > > statement to the effect that the (code)history is complete and known > up to > > > that date and `our responsibility'. > > > > > > With the option; e.g. after 1 or 2 years; for that new community to > > > petition the board for the actual trademarks, domain names and what > not. > > > > > > So basically - we add an Afterlife option to the Attic which is outside > > > the ASF. And this is in addition to, of course, a normal fork of the > attic > > > data under a new effort their own name. > > > > > > With kind regards, > > > > > > Dw. > > > > > > > > > > > > > > > >
