[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Snort: Mass Bug Closing



In response to several issues raised...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191105
  Not having updated signatures is not an issue that should keep snort out
  of stable as administrators may write their own signatures for snort.

  Perhaps however a wishlist bug asking for a comment (to be put in the
  description) about signature updating and snort's value without updated
  signatures should be filed...
I would even go so far to say that perhaps this is more than a wishlist
issue, but as it's likely not RC then this false sense of security should
be documented before snort gets frozen in sarge.

The security updates can usually be backported when applicable.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 and bug 189267
say:
  DSA 297 closes these bugs. It may be worth noting that potato was not
  affected.
What other security issues are there? I made that statement given
information from another party, was I incorrect? I'll look up my
correspondence and even do some testing if you believe that I was wrong.

The ssh precedent of updating non-rc issues in stable was due to no other
clear way to resolve the rc issues and political pressure. As Colin Watson
said, this is also not a good example as there were many bugs caused by
this upgrade.

Imho it's ok to close non-rc bugs on stable (main Debian developers do).
My rational is that we only fix RC bugs on stable.

I like your automated message to some of the bugs, it could probably be
done to most of the bugs. I looked through some of the bugs and saw that:

95153 may not even be applicable to snort in stable but should be RC.

133049 seems to indicate to me that this old snort should probably be
removed from a few archs.

158040 doesn't have your automated message. It means that snort is
unusable. This is likely the problem that was mentioned to you about your
backport. Merge 165555, 176223 with it (also no automated message)? Is
this an upgrade problem?

161659 talks about how a new config file doesn't get generated on even a
fresh install. Perhaps this is the issue in 158040 et al?

165107 suggests that the config file/rule file problem is in sid sarge and
woody? Tagging this correctly may help the testing script...

135603 is an upgrade problem... rules are incompatible. Is this a stable
to stable upgrade?

173331 seems to be related to 158040 (missing config), but talks about how
the cron script fails, patch included.

170580 looks like a problem with the debconf script. A simple, obvious
workaround is mentioned. This sounds like an upgrade problem.

165135 is a policy violation, which versions are affected? Reported well
after woody was released... A quick check of the source code could reveal
the answer.

I don't know if you should close the upgrade bugs as I've heard the
argument "users should only be using stable releases of packages" and I
don't know about snort in potato (is it there? does it upgrade
correctly?).

I'm getting a bit frustrated going through these myself. It seems that
there's a lot of duplication, and (without testing) it looks like many of
these bugs are still in sid.

If you would like help going through these bugs, tagging them correctly,
merging them, closing some, etc. I'd be happy to look even closer.

     Drew Daniels



Reply to: