+1 to this text, seems much less scary to me. Thanks! On Mon, 3 Jan, 2022, 3:12 pm Jan Høydahl, <[email protected]> wrote:
> Here is an alternative text that is more concrete that new users should > choose 8.x, and that 7.7.3 users must take some action. Perhaps this text > has less risk of being interpreted that we don't care about patching > previous versions? > Don't get me wrong, I agree that it would benefit our users to have a > 7.7.4 release. > > > > Textual version: > > <p><b>WARNING: The 7.7.3 release is not patched > for <a href="/security.html">the latest known security vulnerabilities</a>, > and it is still uncertain whether a 7.7.4 release will happen, as 9.0 is > being planned. New users should choose Solr 8.11.1, and existing 7.7.3 > users should either upgrade or take actions to mitigate relevant > vulnerabilities.</b></p> > > Jan > > 3. jan. 2022 kl. 10:02 skrev Jan Høydahl <[email protected]>: > > This is a special situation while we are in the process of releasing 9.0 > and we have previously promised, but then failed to, keep 7.x up to date > with security releases. So I think this clarifies the situation, and once > 9.0 is out we're back to normal, when 7.7 is EOL and 8.11.x is patched. I > think we all intend to keep our promise for 8.11.x. If we pretended > everything was fine, we'd break our promise. > > If, between now and 9.0 release, someone steps up to release a 7.7.4 with > no known vulnerabilities, then we can revert this warning on the download > page. I know you declared interest in being RM, so that possibility is > still there. > > Jan > > 3. jan. 2022 kl. 09:54 skrev Ishan Chattopadhyaya < > [email protected]>: > > This is a huge departure from our previous stance. Earlier, we used to > support bug fixes and critical security updates for the previous major > version. > It is one thing to express our inability to release a security patch for > 7.7.x, it is a whole different matter saying "it should only be used if you > understand the risk and how to manually mitigate vulnerabilities". > This basically tells users that the moment 9.x is released, same will > happen to 8.x line as well. This is absolutely ridiculous for us to do, it > will erode the remaining trust and confidence of users into our project. > > On Sun, Jan 2, 2022 at 10:31 PM Jan Høydahl <[email protected]> wrote: > >> Please review https://github.com/apache/solr-site/pull/65 which adds a >> disclaimer to the Downloads page: >> >> <7x-disclaimer.png> >> >> Jan >> >> 25. des. 2021 kl. 20:38 skrev Jan Høydahl <[email protected]>: >> >> Not only thinking about log4j here. I’m pretty sure 7.7.x is vulnerable >> to several other CVEs over the last 1,5 years too, so we have not followed >> up with patch releases as some users might expect. I’ll propose an edit to >> the download page to make it clear that 7.x is NOT a patched LTS release >> and recommend against its usage. >> >> Jan Høydahl >> >> 25. des. 2021 kl. 17:47 skrev David Smiley <[email protected]>: >> >> >> Users have a valid mitigation that is easy to apply (that sys prop >> =true), and they could upgrade Log4j themselves if they are extra paranoid >> (e.g. corp mandates, which I am familiar with). So I think no further >> action by our project is necessary. >> >> >> (Merry Christmas to you all) >> >> On Fri, Dec 24, 2021 at 11:11 AM Shawn Heisey <[email protected]> >> wrote: >> >>> On 12/24/2021 5:12 AM, Jan Høydahl wrote: >>> > Merry Christmas to all fellow committers and the wider community! >>> > >>> > If there are no plans of (quickly) releasing a 7.7.4 with all known >>> vulnerabilities fixed, I propose we publish a statement that 7.x is >>> officially not supported and urge users to upgrade to 8.11. >>> >>> I agree. 7.x is in maintenance mode until 9.0 is released, and users >>> have a few options for a workaround. If patching and recompiling were >>> the only option for users to fix the problem themselves, then I think we >>> would need to make a new release. >>> >>> Thanks, >>> Shawn >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- >> Sent from Gmail Mobile >> >> >> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
