You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Alex Johnston (Jira)" <ji...@apache.org> on 2022/02/28 15:54:00 UTC
[jira] [Updated] (SOLR-16060) Clarify version lifecycle
[ https://issues.apache.org/jira/browse/SOLR-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Johnston updated SOLR-16060:
---------------------------------
Description:
The official [downloads|https://solr.apache.org/downloads.html] page is ambiguous regarding what versions of Solr are currently supported.
!image-2022-02-28-15-42-49-391.png|width=374,height=136!
In this section it lists
{quote}
|7.7.x Previous major version may sometimes receive critical bugfix releases|
{quote}
and
{quote}
|<7.7|All older versions are End Of Life (EOL)|
{quote}
This implies version 7.7.x is _not_ end of life and < 7.7 is specifically listed as end of life.
The statement 'may sometimes receive critical bugfix releases' for 7.7.x would suggest it would receive critical bugfix releases, of all critical bugfix releases I would've thought security were the most critical.
Higher on the page it is specified:
{quote}*WARNING: The 7.7.3 release is not patched for [the latest known security vulnerabilities|https://solr.apache.org/security.html], and it is still uncertain whether a 7.7.4 release will happen, as 9.0 is currently 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.*
{quote}
Considering the amount of time that has passed since Log4shell I presume it is safe to say 7.7.4 is not coming.
From a normal standpoint this is {_}fine{_}, but I believe from a compliance stand point it does not make sense for 7.7.x not to be listed as EOL if it does not receive critical security fixes in a timely fashion. In our case we are in somewhat of a limbo situation where a major compliance action is taking place and a vulnerability is present but the software being run is that latest version and still being supported.
We have mitigation in place while we're moving to Solr 8, but the simple presence of the vulnerability is adding a significant amount of overhead. It would be preferable simply list it as EOL.
was:
The official downloads page is ambiguous regarding what versions of Solr are currently supported.
!image-2022-02-28-15-42-49-391.png|width=374,height=136!
In this section it lists
{quote}
|7.7.x Previous major version may sometimes receive critical bugfix releases|
{quote}
and
{quote}
|<7.7|All older versions are End Of Life (EOL)|
{quote}
This implies version 7.7.x is _not_ end of life and < 7.7 is specifically listed as end of life.
The statement 'may sometimes receive critical bugfix releases' for 7.7.x would suggest it would receive critical bugfix releases, of all critical bugfix releases I would've thought security were the most critical.
Higher on the page it is specified:
{quote}*WARNING: The 7.7.3 release is not patched for [the latest known security vulnerabilities|https://solr.apache.org/security.html], and it is still uncertain whether a 7.7.4 release will happen, as 9.0 is currently 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.*
{quote}
Considering the amount of time that has passed since Log4shell I presume it is safe to say 7.7.4 is not coming.
From a normal standpoint this is {_}fine{_}, but I believe from a compliance stand point it does not make sense for 7.7.x not to be listed as EOL if it does not receive critical security fixes in a timely fashion. In our case we are in somewhat of a limbo situation where a major compliance action is taking place and a vulnerability is present but the software being run is that latest version and still being supported.
We have mitigation in place while we're moving to Solr 8, but the simple presence of the vulnerability is adding a significant amount of overhead. It would be preferable simply list it as EOL.
> Clarify version lifecycle
> -------------------------
>
> Key: SOLR-16060
> URL: https://issues.apache.org/jira/browse/SOLR-16060
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Affects Versions: 7.7.3
> Reporter: Alex Johnston
> Priority: Minor
> Attachments: image-2022-02-28-15-42-49-391.png
>
>
> The official [downloads|https://solr.apache.org/downloads.html] page is ambiguous regarding what versions of Solr are currently supported.
> !image-2022-02-28-15-42-49-391.png|width=374,height=136!
> In this section it lists
> {quote}
> |7.7.x Previous major version may sometimes receive critical bugfix releases|
> {quote}
> and
> {quote}
> |<7.7|All older versions are End Of Life (EOL)|
> {quote}
> This implies version 7.7.x is _not_ end of life and < 7.7 is specifically listed as end of life.
> The statement 'may sometimes receive critical bugfix releases' for 7.7.x would suggest it would receive critical bugfix releases, of all critical bugfix releases I would've thought security were the most critical.
> Higher on the page it is specified:
> {quote}*WARNING: The 7.7.3 release is not patched for [the latest known security vulnerabilities|https://solr.apache.org/security.html], and it is still uncertain whether a 7.7.4 release will happen, as 9.0 is currently 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.*
> {quote}
> Considering the amount of time that has passed since Log4shell I presume it is safe to say 7.7.4 is not coming.
> From a normal standpoint this is {_}fine{_}, but I believe from a compliance stand point it does not make sense for 7.7.x not to be listed as EOL if it does not receive critical security fixes in a timely fashion. In our case we are in somewhat of a limbo situation where a major compliance action is taking place and a vulnerability is present but the software being run is that latest version and still being supported.
> We have mitigation in place while we're moving to Solr 8, but the simple presence of the vulnerability is adding a significant amount of overhead. It would be preferable simply list it as EOL.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org