This one time, at band camp, Marc Haber said: > Hi, > > On Sun, May 22, 2005 at 07:32:07PM -0400, Stephen Gran wrote: > > In the more general sense, I feel a little like you're trying to > > squeeze freshclam into a more general purpose than it was really > > designed to be. > > Wasn't it designed to download clamav databases?
It was designed as a helper app, like postfix's queue manager. Not necessarily as something runnable as an alternative user, with an alternate home directory, and with separate command line arguments to what the regular clam updater needs. If we had a /usr/libexec this would probably be a candidate for it. > > You can achieve all of the things freshclam does with host/dig, wget > > and sigtool, none of which need any priviledges, or access to a > > config file, and have the side efect of doing the one thing they do > > very well. > > That would, however, mean re-inventing the wheel and having to track > upstream changes to database distribution policy. And it would break > when upstream decides to change its mechanisms. clamav-freshclam is a > documented API to obtaining current databases. But not necessarily for the end user. If you are delivering Debian packages for some part of the clam suite, it would behoove you to follow development trends, and at least keep aware of how upstream delivers the new databases. If you can't do that, using freshclam to do it for you won't band-aid things forever. > > This would effectively meet the needs you've outlined here, and in > > #236829 and #234926. > > 234926 could be confusing in the normal usage scenario. I somewhat > agree with your judgment on #236839. #234926 becomes much clearer if you realize that this is merely a helper app, and not something entirely intended to be user visible. Both clamd and clamav-milter reload the databases if the timestamp on the cvd files is newer than when they last checked. So, since any download should trigger a reload (because freshclam is in charge of deciding when to download), the timestamp should always be as recent as possible. Preserving timestamps could (theoretically) work counter-productively. This _is_ the normal usage scenario. Any other usage is merely a side benefit, and not the intended one. > > I am not trying to change your mind, you understand, just pointing > > out that these 'bugs' are more problems of trying to general- > > purpose a very single purpose tool. > > Is it really bad to do minor changes to a tool to make it more general > while it can still fulfil its single purpose? All changes introduce bugs, and all bugs are not necessarily good. Another way of saying "if it's not broke, don't fix it". However, I don't necessarily disagree with you about some of the things you are asking for - I am just saying that you are pushing the boundaries of what the tool is designed for, so don't be hugely surprised when it fails to exceed it'e design goals. > > > In my opinion, freshclam.conf should be world readable by default, > > > with the documented option for people who use proxy authentication > > > that the permissions on freshclam.conf need to be tightened > > > _then_. But I think that having the permissions on freshclam.conf > > > _that_ tight is way over the top. > > > > > > Please reconsider. > > > > I may, but I have to think of a reasonable way to handle this. Will > > get back to you on this. Take care, > > In the mean time, I am pondering to deliver a suid clamav wrapper for > freshclam with clamav-getfiles. This is up to you, but it seems again like bending over backwards to use the wrong tool for the job. > It is at least a bad bug that freshclam doesn't detect the ENOPERM, > but instead complains about an unconfigured database mirror. Presumably you mean EACCES, but I understand your point. Part of the problem here, of course, is that it reads some entries from each of freshclam.conf and clamd.conf, so neither is a fatal error in and of itself. It just compains and gives up when it notices you've passed no mirror to it. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
pgpE1Mtqdartl.pgp
Description: PGP signature
