On Mon, 2007-07-23 at 15:37 +0100, Stephen Gran wrote: > This one time, at band camp, Jim Popovitch said: > > So avscan (or any other V project) could prevent critical updates from > > reaching end-users. That seems like a security problem to me. > > Suppose some virus spammers convince ($$) some avscan (or other > > project) developer to drag their feet on releasing a fix? > > Then, as I have before, I'll fix the product for volatile myself. The > simplest fix for avscan is to disable a whole swath of functionality in > avscan, so I'd rather not take the simple approach.
I can appreciate that. What I haven't seen/heard is whether or not the avscan folks have even started on an approach. > If the resolution is going to take more than a short while, I can do a > targetted fix to resolve the DoS present in 0.91. Are we talking about waiting 1 day, 1 week, 1 month, or 1 year on the avscan folks? > It is a two line > patch that fixes a bug that does not allow for code execution, so it is > hardly a critical update. New upstream versions are not, by their very > nature, "critical updates" in my mind, sorry. There are some nice > feature fixes in 0.91.1 over 0.91, but none of them so important as to > warrant hyperbole. If the security issues addressed in the latest > release were more severe, I would have already coordinated a volatile > security point release, as I have already done for stable and testing. > > > Wouldn't it be better to advise of the dependent project's problem in > > the release notes, and advise against applying the clamav update on > > just those avscan systems? > > What release notes? You mean a volatile update announcement? Is it OK > with you to break systems where people do automated upgrades? Yes, at some point I do believe it is OK to break systems that depend on other software that isn't maintained in a timely fashion. Is it OK with you to leave a DoS app in production while a less used application waits for an unspecified amount of time to be fixed. Interestingly enough Amavis and other ClamAV dependent applications don't suffer from those nuances. > Even though the charter for volatile says that it is designed to be as easy > to integrate as security.d.o, and it's not just another random backports > site that doesn't mind breaking your system because they don't test? > > > Does murphy.d.o use avscan or clamav? > > I assume it uses clamav, yes. I also assume that the DSA team can > evaluate the risks to the archive and to their machines and make > choices, just like everyone else. > > Sorry if this comes off as angry, but the implication that we're sitting > on our hands giving someone time to break into your systems is a bit > much. No worries, I'm pretty sure you aren't sitting on your own hands. But, I don't really know, so only by raising the issue can I find out the pertinent details that let me know this hasn't fallen under a bridge somewhere. Sorry if my questions strike a nerve, I'd be very happy to hear of alternate approaches to achieve the same resolution. -Jim P. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
