[Snort-sigs] [Emerging-Sigs] [Snort-devel] Snort 2.9.0.1 Now Available

Russ Combs rcombs at ...435...
Wed Nov 3 14:33:09 EDT 2010


Thanks, Mike, for the objective explanation.

On Wed, Nov 3, 2010 at 12:46 PM, Mike Lococo <mikelococo at ...2420...> wrote:

> > This is for /rules/, remember.  Current version, and one back is the
> > standard.  We'll take a look at the life cycle, wording, and policy on
> > the website to see if any modifications need to be made to clarify
> anything.
>
> I think most folks would rather have the practice changed to match the
> written policy than the other way around.  That is: rule support for the
> current version and one *major* version back.
>
> > We can't bring the 2.9.0 or 2.9.0.1 improvements back to 2.8.x.  2.9.0
> > was a big rewrite of the stream model (and many other things) and
> > bringing back the code to 2.8 would, as I said, be a monumental
> > undertaking.  That's why 2.9 was released.
>
> Software-upgrades and security-fixes is a slightly different issue from
> rule-availability, although their timelines should be aligned.  An
> excellent model that many companies use is to put new features into the
> latest major-release (2.9.x, at the moment), and security-fixes only for
> the previous release (2.8.x, at the moment).  This doesn't require
> backporting features and subsystem rewrites, only security-related
> bug-fixes.  Folks on 2.8 (or latest-1) would miss out on new features,
> and maybe on new detection logic that relies on those features.  The
> benefit they would gain is control over when to deploy disruptive
> major-releases and a greater assurance that security-fix releases are
> not going to be disruptive.
>
> >> I can only imagine that SF is trying to push enterprise customers who
> >> care about lifecycle to appliances by promoting what is known to be an
> >> unworkable lifecycle policy.
> >
> > No.  That's not correct.  2.9.0.1 was released, as there were bugs in
> > 2.9.0 that we were able to resolve.  Thusly the patch minor version.  We
> > try to keep the system up to date to deal with the current threats and
> > enhance functionality, all the while giving our open-source community a
> > free product.
>
> No one is advocating that development be stopped, or saying that minor
> upgrades like 2.9 to 2.9.1 are too onerous.  The difficulty for most of
> us is that major upgrades like 2.8 to 2.9 (which has a libpcap version
> dependency that's out of sync with the biggest Linux vendor in the
> world) are being forced with narrow planning and deployment windows due
> to a lifecycle policy based on frequent minor/patch releases instead of
> infrequent major releases.
>
> Cheers,
> Mike Lococo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20101103/fbed88c8/attachment.html>


More information about the Snort-sigs mailing list