Re: [Emerging-Sigs] Downloading older versions of snort

[JP Vossen <jp () jpsdomain org>]

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 () sourcefire com>
>
> On Aug 10, 2012, at 10:29 AM, Mike Cox<mike.cox52 () gmail com>  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 [1].  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... :)  [2]

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 
history.

I also then run into another frustration, the "CLI" [3] downloads often 
don't work right.  For example, for 2.9.3.1 this fails:
$WGET -O "changelog_$VERSION.txt" 
"http://www.snort.org/dl/snort-current/changelog_$VERSION.txt";

but these work:
$WGET -O "snort-$VERSION.tar.gz" 
"http://www.snort.org/dl/snort-current/snort-$VERSION.tar.gz";
$WGET -O "snort-$VERSION.tar.gz.sig" 
"http://www.snort.org/dl/snort-current/snort-$VERSION.tar.gz.sig";
$WGET -O "snort-$VERSION.tar.gz.md5" 
"http://www.snort.org/dl/snort-current/snort-$VERSION.tar.gz.md5";
$WGET -O "snort-$VERSION-1.src.rpm" 
"http://www.snort.org/dl/snort-current/snort-$VERSION-1.src.rpm";
$WGET -O "snort-$VERSION-1.src.rpm.md5" 
"http://www.snort.org/dl/snort-current/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 [4], 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,
JP
__________________________
[1] http://www.snort.org/snort-downloads/rhel5/

[2] 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 [1] are non trivial also.  I didn't 
say it was easy...

[3] http://snort.org/snort-downloads/cli

[4] http://blog.snort.org/2012/02/decommissioning-of-cvs-server-at.html
-- -------------------------|:::======|-------------------------------
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!