You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Shawn Heisey <ap...@elyograg.org> on 2021/12/16 01:42:36 UTC
Should we have an "emergency release" procedure?
The log4j debacle has sure been interesting.
I have heard from at least one user that the project should have reacted
faster to this problem, in order to get a fixed version available
quickly. Our release process takes several days even if everything goes
well, which can be perceived by users as indifference in the face of a
security concern.
What I am thinking is that we might want to have an emergency release
process that consists of checking out the tag for the most current
release available, making as small a change as possible to address a
vulnerability, and then releasing it quickly, skipping as much of the
usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4
hours or 8 hours. The first number that popped into my fron was 24
hours, but that's still a pretty long delay for a major problem like the
log4j vulnerability.
If the versioning code in Solr can deal with it, what I would think of
as the version number for a special release in this case would be
8.10.0.1 -- to indicate that it is almost completely identical to
8.10.0. If the versioning code can't deal with it, I propose that we
alter it so that it can.
Thoughts from my fellow committers? Is this idea completely bonkers?
Would there be changes to the idea that might make it better?
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Should we have an "emergency release" procedure?
Posted by Jan Høydahl <ja...@cominvent.com>.
For emergency releases, we could strive to have at least 6 +1 votes (double of normal), and go the extra mile of testing more than smoketester. That should weigh up for a shorter 24h cycle.
Jan
> 16. des. 2021 kl. 15:30 skrev Gus Heck <gu...@gmail.com>:
>
> I think it's fine to have a 24h vote period for "Security" releases, Such releases should be a regular x.y.z version number, no need for a 4th digit. 3rd digit is already bugfixes only. I think a CVE on ous or a dependency that is RCE or information disclosure should be the trigger, and only a bugfix release can get expedited of course. Otherwise normal release. I don't think we should shorten it too far, witness how new information became available regarding further vulnerability.mitigation in this case. Not great to issue releases too quickly as it can lead to releasing something in error with a false sense of security. So if we can shave a couple days of fine, but let's also give some time for proper consideration too.
>
> On Thu, Dec 16, 2021 at 4:01 AM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
> Hi,
>
> I agree that we should better take the option to have fast releases. We should maybe make a rule how many LOC is allowed to shorten the period.
>
> About the versioning: I would not change the versioning and just add 1 to the minor release. Plain simple.
>
> Longer story: If you still want a fourth digit, the versioning schema can handle this, but the lowest bits (in binary, digits in text form) have some special meaning (ALPHA, BETA,...) in Lucene's Version.java. So my proposal for that route would be: As Solr needs its own Version.java anyways (SolrVersion.java), you can implement it there. But be aware, there's also Gradle magic and release automation involved.
>
> For Lucene there's no need for those type of releases, as we are a library only.
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>
> > -----Original Message-----
> > From: Shawn Heisey <apache@elyograg.org <ma...@elyograg.org>>
> > Sent: Thursday, December 16, 2021 2:43 AM
> > To: dev@solr.apache.org <ma...@solr.apache.org>
> > Subject: Should we have an "emergency release" procedure?
> >
> > The log4j debacle has sure been interesting.
> >
> > I have heard from at least one user that the project should have reacted
> > faster to this problem, in order to get a fixed version available
> > quickly. Our release process takes several days even if everything goes
> > well, which can be perceived by users as indifference in the face of a
> > security concern.
> >
> > What I am thinking is that we might want to have an emergency release
> > process that consists of checking out the tag for the most current
> > release available, making as small a change as possible to address a
> > vulnerability, and then releasing it quickly, skipping as much of the
> > usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4
> > hours or 8 hours. The first number that popped into my fron was 24
> > hours, but that's still a pretty long delay for a major problem like the
> > log4j vulnerability.
> >
> > If the versioning code in Solr can deal with it, what I would think of
> > as the version number for a special release in this case would be
> > 8.10.0.1 -- to indicate that it is almost completely identical to
> > 8.10.0. If the versioning code can't deal with it, I propose that we
> > alter it so that it can.
> >
> > Thoughts from my fellow committers? Is this idea completely bonkers?
> > Would there be changes to the idea that might make it better?
> >
> > Thanks,
> > Shawn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org <ma...@solr.apache.org>
> > For additional commands, e-mail: dev-help@solr.apache.org <ma...@solr.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org <ma...@solr.apache.org>
> For additional commands, e-mail: dev-help@solr.apache.org <ma...@solr.apache.org>
>
>
>
> --
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
Re: Should we have an "emergency release" procedure?
Posted by Gus Heck <gu...@gmail.com>.
I think it's fine to have a 24h vote period for "Security" releases, Such
releases should be a regular x.y.z version number, no need for a 4th digit.
3rd digit is already bugfixes only. I think a CVE on ous or a dependency
that is RCE or information disclosure should be the trigger, and only a
bugfix release can get expedited of course. Otherwise normal release. I
don't think we should shorten it too far, witness how new information
became available regarding further vulnerability.mitigation in this case.
Not great to issue releases too quickly as it can lead to releasing
something in error with a false sense of security. So if we can shave a
couple days of fine, but let's also give some time for proper consideration
too.
On Thu, Dec 16, 2021 at 4:01 AM Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> I agree that we should better take the option to have fast releases. We
> should maybe make a rule how many LOC is allowed to shorten the period.
>
> About the versioning: I would not change the versioning and just add 1 to
> the minor release. Plain simple.
>
> Longer story: If you still want a fourth digit, the versioning schema can
> handle this, but the lowest bits (in binary, digits in text form) have some
> special meaning (ALPHA, BETA,...) in Lucene's Version.java. So my proposal
> for that route would be: As Solr needs its own Version.java anyways
> (SolrVersion.java), you can implement it there. But be aware, there's also
> Gradle magic and release automation involved.
>
> For Lucene there's no need for those type of releases, as we are a library
> only.
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Shawn Heisey <ap...@elyograg.org>
> > Sent: Thursday, December 16, 2021 2:43 AM
> > To: dev@solr.apache.org
> > Subject: Should we have an "emergency release" procedure?
> >
> > The log4j debacle has sure been interesting.
> >
> > I have heard from at least one user that the project should have reacted
> > faster to this problem, in order to get a fixed version available
> > quickly. Our release process takes several days even if everything goes
> > well, which can be perceived by users as indifference in the face of a
> > security concern.
> >
> > What I am thinking is that we might want to have an emergency release
> > process that consists of checking out the tag for the most current
> > release available, making as small a change as possible to address a
> > vulnerability, and then releasing it quickly, skipping as much of the
> > usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4
> > hours or 8 hours. The first number that popped into my fron was 24
> > hours, but that's still a pretty long delay for a major problem like the
> > log4j vulnerability.
> >
> > If the versioning code in Solr can deal with it, what I would think of
> > as the version number for a special release in this case would be
> > 8.10.0.1 -- to indicate that it is almost completely identical to
> > 8.10.0. If the versioning code can't deal with it, I propose that we
> > alter it so that it can.
> >
> > Thoughts from my fellow committers? Is this idea completely bonkers?
> > Would there be changes to the idea that might make it better?
> >
> > Thanks,
> > Shawn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Should we have an "emergency release" procedure?
Posted by Shawn Heisey <el...@elyograg.org>.
On 12/16/2021 2:00 AM, Uwe Schindler wrote:
> About the versioning: I would not change the versioning and just add 1 to the minor release. Plain simple.
Fair enough. And I am not surprised to see people advocating it. A
fourth component to the version number is definitely an extra burden
that would probably mean changes to things I haven't even thought of.
I don't know if it's a good idea to put arbitrary limits like "less than
X lines of code" for an emergency release. Some changes with near zero
functional impact could end up being thousands of lines when expressed
as a diff. Of course we should try to avoid that. I think there should
be two parts to the justification:
1) Fixes show-stopper bug or security vulnerability SOLR-NNNNN. Maybe
multiple issue numbers in some cases.
2) The change ONLY addresses those specific problems, and is as small as
we can make it.
As I mentioned, changes for an emergency release should come from a new
branch that starts with the last release tag, rather than the stable
development branch like standard releases.
I like Jan's idea of requiring more +1 votes than a standard release.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
RE: Should we have an "emergency release" procedure?
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
I agree that we should better take the option to have fast releases. We should maybe make a rule how many LOC is allowed to shorten the period.
About the versioning: I would not change the versioning and just add 1 to the minor release. Plain simple.
Longer story: If you still want a fourth digit, the versioning schema can handle this, but the lowest bits (in binary, digits in text form) have some special meaning (ALPHA, BETA,...) in Lucene's Version.java. So my proposal for that route would be: As Solr needs its own Version.java anyways (SolrVersion.java), you can implement it there. But be aware, there's also Gradle magic and release automation involved.
For Lucene there's no need for those type of releases, as we are a library only.
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Shawn Heisey <ap...@elyograg.org>
> Sent: Thursday, December 16, 2021 2:43 AM
> To: dev@solr.apache.org
> Subject: Should we have an "emergency release" procedure?
>
> The log4j debacle has sure been interesting.
>
> I have heard from at least one user that the project should have reacted
> faster to this problem, in order to get a fixed version available
> quickly. Our release process takes several days even if everything goes
> well, which can be perceived by users as indifference in the face of a
> security concern.
>
> What I am thinking is that we might want to have an emergency release
> process that consists of checking out the tag for the most current
> release available, making as small a change as possible to address a
> vulnerability, and then releasing it quickly, skipping as much of the
> usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4
> hours or 8 hours. The first number that popped into my fron was 24
> hours, but that's still a pretty long delay for a major problem like the
> log4j vulnerability.
>
> If the versioning code in Solr can deal with it, what I would think of
> as the version number for a special release in this case would be
> 8.10.0.1 -- to indicate that it is almost completely identical to
> 8.10.0. If the versioning code can't deal with it, I propose that we
> alter it so that it can.
>
> Thoughts from my fellow committers? Is this idea completely bonkers?
> Would there be changes to the idea that might make it better?
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org