On Sat, Oct 09, 2004 at 03:54:11PM -0400, Kevin Mark wrote: > On Sat, Oct 09, 2004 at 04:37:14PM +0100, paddy wrote: > > On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote: > > > This one time, at band camp, Kevin Mark said: > > > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine > > > > wrote: > > > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote: > > > > > > Packages like virus checkers seem to be > > > > > > composed of 2 parts: the app program and the data where the data in > > > > > > this case are virus sigs and the app is say clamav. And the > > > > > > 'volitile' > > > > > > part is the virus sigs whereas the app (once it hits stable) > > > > > > shouldnt > > > > > > change unless it warrents a 'security' update. So, volitile should > > > > > > be > > > > > > for the data/virus sigs that need updating when new bugs hit the > > > > > > 'net. > > > > > > > > > > No, often such kind of programs need engine update. That's true for > > > > > both AV and antispam programs as well. > > > > > > > > > Hi Francesco, > > > > so: > > > > the program = engine part + (some un-named part) ??? > > > > and the engine part and the data part are volitile > > > > > <snip> > > > > > > Right now, it is easy enough to get new data sets - the clamav suite > > > inculdes an updater for it's data, and spamassassin is easy to add new > > > rules to. The problem is updating the engine in a stable release. > > > > Indeed, there is a consensus that data updates with the volatility > > of, say, virus scanner sigs belong firmly out-of-band. > > Hi Paddy, > so that leaves libs and frontends (at least for clamav) > but I thought the ideas was to protect against virus threats? > > if its out-of-band (not in debian control) than the only thing that > would seem reasonable is to convert between any new data format and the > data format used in stable.
maybe there is a place for this, but my understanding is the evolution of data formats is coupled to changes in the scaning engine and backward compatibility is maintained upstream for as long as the upstream maintainers deem reasonable. It may be that engines will eventually evolve to the point where these changes happen on the timescale of a debian stable release, then again it may be in the nature of the problem that they never will. Noone seems to be suggesting that the former is on the immediate horizon (as they are for mozilla for example). I am arguing the latter. > current stable= > no changes to package = stable system with security left to user for clamav, i would hope security.d.o to cover as usual. and virus scanning is not generally about protecting linux hosts. So I see it as a question of function rather than security, in this case. > with volitile=backport data format= > stable system with some new data to improve security somewhat maybe, see above. > with volitile=backport lib, frontends,data?= > possible unstable system with possibly up-to-data security clamav is a really good example of a very self-contained, at least in some setups. two pipes, no privs (someone corrrect me if I'm wrong). In the case of clamav, what i believe is at issue is not the stability or security of whole individual systems (possibly the clamav function) but importantly the stability of the archive, that system. > Dont take the above as anything other than my overexagerated guess. > I'm just thinking it through to see if I can squeeze this into me wee > brain! It's great to talk with you. The more I look at it, the more of the complexity of the problem I see. I hope you can find plenty more room in there ;) Regards, Paddy > -Kev > -- > > (__) > (oo) > /------\/ > / | || > * /\---/\ > ~~ ~~ > ...."Have you mooed today?"... -- Perl 6 will give you the big knob. -- Larry Wall
