[Snort-sigs] [Emerging-Sigs] Downloading older versions of snort
jp at ...1432...
Fri Aug 10 16:05:14 EDT 2012
I see more messages have happened since I started writing this, so sorry
to break up the flow a bit.
> Date: Fri, 10 Aug 2012 10:55:06 -0400
> From: Joel Esler<jesler at ...435...>
> On Aug 10, 2012, at 10:29 AM, Mike Cox<mike.cox52 at ...2420...> wrote:
>> >Thanks Joel. Ultimately I would like to be able to
>> >download/compile/run/analyze snort 2.8 versions thru the current
>> >version. Do you have links?
> They aren't publicly available, I'll have to dig them out from storage somewhere.
That has long been a frustration for me too. I understand wanting to
strongly encourage folks to use the latest, but there are 2 points here.
First, if you want folks to do that, you have to make it easy and
"compliant" to do so with common OS & distro versions. IMO, with
RHEL/CentOS-5, you don't . This has been beaten to death before and
I seem to be in the minority so enough said. And I can't think of a
better word than compliant, but what I mean is staying inside the
OS/Distro package system and "way to do things." Compiling from source
on CentOS is neither compliant nor trivial. (Compiling from source is
fine on Gentoo... :) 
Second, "strongly encourage" should not mean "old versions inaccessible"
IMO. I haven't looked extensively, but I'm not aware of any other
project that is this strict, especially in the face of user push-back.
And consider this a 1+ push-back vote for making older version available.
That said, the older versions don't have to be *easily* available. You
can make it harder to get them, like having to create an account and set
a "make older versions available" checkbox or something.
>> >I guess I could start my own repo of snort versions going forward (I'm
>> >guessing this is OK since it would be publicly available and Snort is
>> >Open Source) but I don't think it would come in handy form for another
>> >two to five years.
That was my solution, and I suspect other folks on the list. But all of
those are probably private (mine is), and I must admit I haven't been as
consistent about it as I'd like, so I don't have 100% of even recent
I also then run into another frustration, the "CLI"  downloads often
don't work right. For example, for 22.214.171.124 this fails:
$WGET -O "changelog_$VERSION.txt"
but these work:
$WGET -O "snort-$VERSION.tar.gz"
$WGET -O "snort-$VERSION.tar.gz.sig"
$WGET -O "snort-$VERSION.tar.gz.md5"
$WGET -O "snort-$VERSION-1.src.rpm"
$WGET -O "snort-$VERSION-1.src.rpm.md5"
So *every time* there is a release I have to run my download script,
then manually see what failed, and manually go fix it, like:
$WGET -O "changelog_$VERSION.txt" "http://snort.org/downloads/1837"
Not a huge deal, but frustrating and seemingly inconsistent (as to which
link(s) break from release to release).
> Like I said before, maybe we can put them up somewhere for reference and people can get to them. I need to think about what's the best way to do that (considering our backend hosting, etc)
That'd be very nice! While I can make arguments about historical
versions being useful for regression testing, various corporate
policy/speed issues, etc. I have to admit that part of it is mental.
I'm personally just more comfortable (more warm fuzzies) when I can see
the old versions. Call me an old fuddy if you like, but there it is...
>> > Maybe someone better at Sourceforge/github/etc.
Especially since cvs.snort.org went away , the entire repo at github
or launchpad would be nice. Snort is a part of Internet InfoSec
history, and having that full history available would be very cool. For
that matter, any of the hosting sites could also host historical
binaries if "snort.org" is too complicated.
>> >could do this and/or Sourcefire could assist since they have all the
>> >code (and aren't scared of the past or being fully Open Source).
> I don't understand your "fully Open Source" comment. We've never hid anything. Our code has always been open source, and as long as Marty is around, always will be.
I think it's an attitude thing. Most F/OSS projects don't presume, like
MS and Apple do, to tell you what to do and that they know better than
you do what your needs are. SF, I'm sorry to say, does do that with
Snort, as per this thread. Maybe not on purpose, but...
With all of the above said, I don't mean to sound negative or anything.
I understand corporate pressures on resources (boy do I), so this is
from the F/OSS perspective, not the corporate one. And I think that
most of us understand that Snort in general and Joel in particular are
very much caught in the middle... :-)
Also, these things do take time, but I find that ironic since the pace
of Snort releases often seems to move far faster than "corporate time"
allows for... :-)
My personal $0.02,
 Lots of folks will have policy that disallows compilers on security
devices (why, when Perl is there, but that's a different issue). Yes,
you should use a buildhost to build RPMs and go from there, but that
takes time, resources and skills not everyone has. It can then also
turn into the "if you can't compile from source you shouldn't be using
it" argument which gets ugly fast. And the reasons that compiling from
source is a pain on RHEL/CentOS-5  are non trivial also. I didn't
say it was easy...
JP Vossen, CISSP |:::======| http://bashcookbook.com/
My Account, My Opinions |=========| http://www.jpsdomain.org/
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
More information about the Snort-sigs