Security releases

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Security releases

David Blevins-2
So as I mentioned in the security reporting thread, although we do always use the most recent versions of everything in our releases, we should probably address our timing.

Over the lifetime of TomEE we average 4.14 months between releases.  Also in the lifetime of TomEE, there've been about 18 CVEs that affect us.  That's one every 1.61 months.

On top of that, once a new TomEE 1.x version comes out we don't really keep supporting the previous 1.x release, which we should -- at least for security fixes.

 - - -

The fastest and most realistic way I can see to continuously turn out releases that contain security updates with the least amount time is to:

  - branch from the latest supported tags (1.5.x, 1.6.x)
  - apply the security patch or do the library upgrade
  - release them as 1.5.x.y, 1.6.x.y

My gut says anything else will just encounter the usual 4 month delay.  As well I can see there being a significant advantage to having security only releases:

  - a lot easier to do the legal screening, code header scanning, etc.
  - far less community time spent on rigorously testing all our applications
  - less regression testing users have to do to upgrade.  (We're always adding new features to 1.x.y releases)
  - doesn't disrupt or put pressure on our development cycle

With the current Tomcat CVE now fixed, that'd give us:

 - 1.5.2.1
 - 1.6.0.1

Thoughts?


-David





Reply | Threaded
Open this post in threaded view
|

Re: Security releases

Jean-Louis MONTEIRO
+1 looks good.

Just regarding the latest digit, was wondering is we could use instead:
su1, security update 1
sec01, security 01

The latest one is the more commonly used.

JLouis


2014-02-19 18:08 GMT+01:00 David Blevins <[hidden email]>:

> So as I mentioned in the security reporting thread, although we do always
> use the most recent versions of everything in our releases, we should
> probably address our timing.
>
> Over the lifetime of TomEE we average 4.14 months between releases.  Also
> in the lifetime of TomEE, there've been about 18 CVEs that affect us.
>  That's one every 1.61 months.
>
> On top of that, once a new TomEE 1.x version comes out we don't really
> keep supporting the previous 1.x release, which we should -- at least for
> security fixes.
>
>  - - -
>
> The fastest and most realistic way I can see to continuously turn out
> releases that contain security updates with the least amount time is to:
>
>   - branch from the latest supported tags (1.5.x, 1.6.x)
>   - apply the security patch or do the library upgrade
>   - release them as 1.5.x.y, 1.6.x.y
>
> My gut says anything else will just encounter the usual 4 month delay.  As
> well I can see there being a significant advantage to having security only
> releases:
>
>   - a lot easier to do the legal screening, code header scanning, etc.
>   - far less community time spent on rigorously testing all our
> applications
>   - less regression testing users have to do to upgrade.  (We're always
> adding new features to 1.x.y releases)
>   - doesn't disrupt or put pressure on our development cycle
>
> With the current Tomcat CVE now fixed, that'd give us:
>
>  - 1.5.2.1
>  - 1.6.0.1
>
> Thoughts?
>
>
> -David
>
>
>
>
>
>


--
Jean-Louis
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|

Re: Security releases

Bjorn Danielsson
In reply to this post by David Blevins-2
+1 for having quick and minimal effort security-only releases.

At least for updating the latest release in cases where the
patch has limited impact on everything else ("minimal effort").

--
Bjorn Danielsson
Cuspy Code AB


David Blevins <[hidden email]> wrote:

> So as I mentioned in the security reporting thread, although we do always use the most recent versions of everything in our releases, we should probably address our timing.
>
> Over the lifetime of TomEE we average 4.14 months between releases.  Also in the lifetime of TomEE, there've been about 18 CVEs that affect us.  That's one every 1.61 months.
>
> On top of that, once a new TomEE 1.x version comes out we don't really keep supporting the previous 1.x release, which we should -- at least for security fixes.
>
>  - - -
>
> The fastest and most realistic way I can see to continuously turn out releases that contain security updates with the least amount time is to:
>
>   - branch from the latest supported tags (1.5.x, 1.6.x)
>   - apply the security patch or do the library upgrade
>   - release them as 1.5.x.y, 1.6.x.y
>
> My gut says anything else will just encounter the usual 4 month delay.  As well I can see there being a significant advantage to having security only releases:
>
>   - a lot easier to do the legal screening, code header scanning, etc.
>   - far less community time spent on rigorously testing all our applications
>   - less regression testing users have to do to upgrade.  (We're always adding new features to 1.x.y releases)
>   - doesn't disrupt or put pressure on our development cycle
>
> With the current Tomcat CVE now fixed, that'd give us:
>
>  - 1.5.2.1
>  - 1.6.0.1
>
> Thoughts?
>
>
> -David
Reply | Threaded
Open this post in threaded view
|

Re: Security releases

Romain Manni-Bucau
+1 if possible (the issue will be to upgrade a lib without uprgading
to next version, can need as much work as upgrading to trunk
sometimes...)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-19 20:27 GMT+01:00 Bjorn Danielsson <[hidden email]>:

> +1 for having quick and minimal effort security-only releases.
>
> At least for updating the latest release in cases where the
> patch has limited impact on everything else ("minimal effort").
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> David Blevins <[hidden email]> wrote:
>> So as I mentioned in the security reporting thread, although we do always use the most recent versions of everything in our releases, we should probably address our timing.
>>
>> Over the lifetime of TomEE we average 4.14 months between releases.  Also in the lifetime of TomEE, there've been about 18 CVEs that affect us.  That's one every 1.61 months.
>>
>> On top of that, once a new TomEE 1.x version comes out we don't really keep supporting the previous 1.x release, which we should -- at least for security fixes.
>>
>>  - - -
>>
>> The fastest and most realistic way I can see to continuously turn out releases that contain security updates with the least amount time is to:
>>
>>   - branch from the latest supported tags (1.5.x, 1.6.x)
>>   - apply the security patch or do the library upgrade
>>   - release them as 1.5.x.y, 1.6.x.y
>>
>> My gut says anything else will just encounter the usual 4 month delay.  As well I can see there being a significant advantage to having security only releases:
>>
>>   - a lot easier to do the legal screening, code header scanning, etc.
>>   - far less community time spent on rigorously testing all our applications
>>   - less regression testing users have to do to upgrade.  (We're always adding new features to 1.x.y releases)
>>   - doesn't disrupt or put pressure on our development cycle
>>
>> With the current Tomcat CVE now fixed, that'd give us:
>>
>>  - 1.5.2.1
>>  - 1.6.0.1
>>
>> Thoughts?
>>
>>
>> -David
Reply | Threaded
Open this post in threaded view
|

Re: Security releases

Jean-Louis MONTEIRO
Agree with the possible more work, but it should be hopefully for us, isn't
it?
I mean, the main goal is to have limited changes so that customers/users
are confident in upgrading.

So, if more work for us, but less for users, the target is achieved IMHO.

JLouis


2014-02-19 21:54 GMT+01:00 Romain Manni-Bucau <[hidden email]>:

> +1 if possible (the issue will be to upgrade a lib without uprgading
> to next version, can need as much work as upgrading to trunk
> sometimes...)
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-19 20:27 GMT+01:00 Bjorn Danielsson <
> [hidden email]>:
> > +1 for having quick and minimal effort security-only releases.
> >
> > At least for updating the latest release in cases where the
> > patch has limited impact on everything else ("minimal effort").
> >
> > --
> > Bjorn Danielsson
> > Cuspy Code AB
> >
> >
> > David Blevins <[hidden email]> wrote:
> >> So as I mentioned in the security reporting thread, although we do
> always use the most recent versions of everything in our releases, we
> should probably address our timing.
> >>
> >> Over the lifetime of TomEE we average 4.14 months between releases.
>  Also in the lifetime of TomEE, there've been about 18 CVEs that affect us.
>  That's one every 1.61 months.
> >>
> >> On top of that, once a new TomEE 1.x version comes out we don't really
> keep supporting the previous 1.x release, which we should -- at least for
> security fixes.
> >>
> >>  - - -
> >>
> >> The fastest and most realistic way I can see to continuously turn out
> releases that contain security updates with the least amount time is to:
> >>
> >>   - branch from the latest supported tags (1.5.x, 1.6.x)
> >>   - apply the security patch or do the library upgrade
> >>   - release them as 1.5.x.y, 1.6.x.y
> >>
> >> My gut says anything else will just encounter the usual 4 month delay.
>  As well I can see there being a significant advantage to having security
> only releases:
> >>
> >>   - a lot easier to do the legal screening, code header scanning, etc.
> >>   - far less community time spent on rigorously testing all our
> applications
> >>   - less regression testing users have to do to upgrade.  (We're always
> adding new features to 1.x.y releases)
> >>   - doesn't disrupt or put pressure on our development cycle
> >>
> >> With the current Tomcat CVE now fixed, that'd give us:
> >>
> >>  - 1.5.2.1
> >>  - 1.6.0.1
> >>
> >> Thoughts?
> >>
> >>
> >> -David
>



--
Jean-Louis
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|

Re: Security releases

Alan Cabrera
In reply to this post by Jean-Louis MONTEIRO
+1 - good idea

As for the su1 or sec01 suffixes, I was thinking the same thing as well but now I prefer the additional .1 instead.  The reason is it makes it easier for tooling to compare versions.  jm2c.


Regards,
Alan


On Feb 19, 2014, at 11:16 AM, Jean-Louis MONTEIRO <[hidden email]> wrote:

> +1 looks good.
>
> Just regarding the latest digit, was wondering is we could use instead:
> su1, security update 1
> sec01, security 01
>
> The latest one is the more commonly used.
>
> JLouis
>
>
> 2014-02-19 18:08 GMT+01:00 David Blevins <[hidden email]>:
>
>> So as I mentioned in the security reporting thread, although we do always
>> use the most recent versions of everything in our releases, we should
>> probably address our timing.
>>
>> Over the lifetime of TomEE we average 4.14 months between releases.  Also
>> in the lifetime of TomEE, there've been about 18 CVEs that affect us.
>> That's one every 1.61 months.
>>
>> On top of that, once a new TomEE 1.x version comes out we don't really
>> keep supporting the previous 1.x release, which we should -- at least for
>> security fixes.
>>
>> - - -
>>
>> The fastest and most realistic way I can see to continuously turn out
>> releases that contain security updates with the least amount time is to:
>>
>>  - branch from the latest supported tags (1.5.x, 1.6.x)
>>  - apply the security patch or do the library upgrade
>>  - release them as 1.5.x.y, 1.6.x.y
>>
>> My gut says anything else will just encounter the usual 4 month delay.  As
>> well I can see there being a significant advantage to having security only
>> releases:
>>
>>  - a lot easier to do the legal screening, code header scanning, etc.
>>  - far less community time spent on rigorously testing all our
>> applications
>>  - less regression testing users have to do to upgrade.  (We're always
>> adding new features to 1.x.y releases)
>>  - doesn't disrupt or put pressure on our development cycle
>>
>> With the current Tomcat CVE now fixed, that'd give us:
>>
>> - 1.5.2.1
>> - 1.6.0.1
>>
>> Thoughts?
>>
>>
>> -David
>>
>>
>>
>>
>>
>>
>
>
> --
> Jean-Louis

Reply | Threaded
Open this post in threaded view
|

Re: Security releases

agumbrecht
+1 for 4 digits.

1 = Usually breaks stuff, be careful
2 = Significant new feature that 'should' not break existing, testing advised.
3 = Fixes or improves something, but also does not or should not break existing.
4 = A security fix that 'may' break something specifically related to the issue.

Andy.
    --
    Andy Gumbrecht

    http://www.tomitribe.com
    agumbrecht@tomitribe.com
    https://twitter.com/AndyGeeDe

    TomEE treibt Tomitribe ! | http://tomee.apache.org