I quite agree with Phil. I think it's really the question of managing expectations. If we will start releasing attic'd projects - even a single one, the implicit expectation will be that we do it for all of them.
As Phil wrote - users (or even those bounty hunters) can - if they **really** want - fork and build and release their own fork of the project. I think the only expectations from the attic'd project should be that it **can** be built (having sufficient tools and systems) - so this is something that should be clearly documented and explained. It's something that we do already for some convenience binaries in Airflow (in a way). For example when we release Airflow's "container image" - which contains system and other dependencies installed, we generally never release a new version of that image with specific Airflow version (which could include upgrade to OS or upgrade dependencies in which new security vulnerabilities have been found. We are often asked for it by our users but then we simply direct them to this page [1] - where we explain in detail why we fix those images in release time, and we provide all the options the users have in this case (basically upgrade airflow to latest version or build your own version of the image - using latest sources and upgrade dependencies you need to upgrade) and we provide very detailed instructions on how to do. I think this should be the expectations of our users - that at the moment the project is "fixed" in the attic - it is in the stage that allows anyone to follow the instructions and build it from a fork - after applying any fixes they want. [1] Information and build instructions how to build a new version of image - https://airflow.apache.org/docs/docker-stack/index.html#fixing-images-at-release-time J. On Thu, Oct 10, 2024 at 4:47 PM Phil Steitz <p...@steitz.com> wrote: > > > > On Oct 10, 2024, at 8:12 AM, Mark Thomas <ma...@apache.org> wrote: > > > > 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? > > I don’t much like that idea. What happens when the next vulnerability > pops up? If there is a community interested in developing the software, > they absolutely can bring it out of the attic. But if it is just > effectively a sanctioned fork to fix designated issues with no implied > commitment to support, I don’t think that is a good idea. Part of the > reason I don’t like it is that if the project is dead, our message should > be, “dead - don’t use, or fork at your own risk”. It is worse to string > users along. I don’t like it when commercial vendors do that kind of > thing: provide post-EOL support for a price for the same reason. Just > delays pain and can lead to unanticipated further pain along the way. > > Another way to look at this is to imagine you are on the ersatz PMC that > votes on the patch release. What does your “+1” actually mean? > > Finally, the license already allows people to fork and fix. The only > advantage to doing it in this kind of sanctioned way is to attach the > Apache brand to the product, which I think would be misleading unless there > was a community behind it. > > Phil > > > > Thoughts? > > > > 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 > >
