Mailing List Archive

The upcoming 15 April kill-switch
Hi,

I have a question about the CVD that will "contain a special signature
which disables all clamd installations older than 0.95." What exactly
will this do?

Will old versions always report "No virus"?

Or will they always report "Virus?"

Or will they always report an error?

Regards,

David.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/07/2010 09:21 PM, David F. Skoll wrote:
> Hi,
>
> I have a question about the CVD that will "contain a special signature
> which disables all clamd installations older than 0.95." What exactly
> will this do?
>
> Will old versions always report "No virus"?
>
> Or will they always report "Virus?"
>
> Or will they always report an error?

It will refuse to load the database and print an error message.

Best regards,
--Edwin
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Am 07.04.10 21:29, schrieb Török Edwin:
> On 04/07/2010 09:21 PM, David F. Skoll wrote:
>> Hi,
>>
>> I have a question about the CVD that will "contain a special signature
>> which disables all clamd installations older than 0.95." What exactly
>> will this do?
>>
>> Will old versions always report "No virus"?
>>
>> Or will they always report "Virus?"
>>
>> Or will they always report an error?
>
> It will refuse to load the database and print an error message.

even refusing to load existing signatures?

>
> Best regards,
> --Edwin
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/07/2010 10:31 PM, Marc Balmer wrote:
> Am 07.04.10 21:29, schrieb Török Edwin:
>> On 04/07/2010 09:21 PM, David F. Skoll wrote:
>>> Hi,
>>>
>>> I have a question about the CVD that will "contain a special signature
>>> which disables all clamd installations older than 0.95." What exactly
>>> will this do?
>>>
>>> Will old versions always report "No virus"?
>>>
>>> Or will they always report "Virus?"
>>>
>>> Or will they always report an error?
>> It will refuse to load the database and print an error message.
>
> even refusing to load existing signatures?

"Will refuse to load" means that daily.cvd will be considered a
malformed database by ClamAV <= 0.94.2.

If you have a malformed database you get an error message, and
clamd/clamscan will exit with an error without scanning anything.

The error message will tell about the End-of-Life status, and what to do
about it.

Best regards,
--Edwin
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
(I apologize for breaking threading; I read clamav-devel in digest
mode)

Török Edwin wrote:

> "Will refuse to load" means that daily.cvd will be considered a
> malformed database by ClamAV <= 0.94.2.

> If you have a malformed database you get an error message, and
> clamd/clamscan will exit with an error without scanning anything.

> The error message will tell about the End-of-Life status, and what to do
> about it.

OK. That's bad. Really bad. It's an enormous problem for us.

We have some customers (I don't know exactly how many) who are
running ClamAV <= 0.94.2. When this hits the ether, their mail
servers will tempfail all mail because clamd will error out.

This might even put us in legal difficulties: some of our customers
have contracts with us in which we assert our software has no "kill
switch" that can disable mail delivery. Thanks to the fine ClamAV
developers, we've been shipping a kill-switch for years.

I know ClamAV is free software; I guess we get what we pay for. But I
really wish you'd be more considerate of your users. It's not the
first time a large, disruptive change has been pushed on us. It's
getting to the point where we're seriously considering either
abandoning or forking ClamAV; we can't cope with the emergencies you
keep forcing on us.

Regards,

David.

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/07/2010 11:47 PM, David F. Skoll wrote:
> (I apologize for breaking threading; I read clamav-devel in digest
> mode)
>
> Török Edwin wrote:
>
>> "Will refuse to load" means that daily.cvd will be considered a
>> malformed database by ClamAV <= 0.94.2.
>
>> If you have a malformed database you get an error message, and
>> clamd/clamscan will exit with an error without scanning anything.
>
>> The error message will tell about the End-of-Life status, and what to do
>> about it.
>
> OK. That's bad. Really bad. It's an enormous problem for us.

Would you prefer freshclam/ClamAV crash/corrupt memory when loading the
new databases with >980 byte lines?

> we can't cope with the emergencies you
> keep forcing on us.

The initial announcement about this was 6 month ago.
If a 6 month window to upgrade is not enough, what would be?

Best regards,
--Edwin
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
David,

While I agree, to some extent, with your concerns, I cannot help but wonder why you waited until now to raise this issue. The fact that ClamAV <=0.94 would stop working on April 15 was first announced six months ago, on October 6, 2009. Surely this question would have been better asked then, when you had more than six months to plan for the change, rather than now, when you have only 8 days.

My company had hundreds of appliances in the field running versions of ClamAV affected by this change. When we saw the announcement, we immediately started working on figuring out how we were going to get them updated by April 15, and we succeeded in doing so.

I agree with you that ClamAV 0.94 was end-of-lifed too early. I, too, think it was unreasonable for the ClamAV developers to kill a software version that was released less than 2 years ago and obsoleted only a year ago. Nevertheless, if your company is currently facing an "emergency" because of this change, then you seem to have forced it upon yourselves by waiting this long to figure out how to address it.

Jik

--
Jonathan Kamens
Operations Manager
Advent Tamale RMS
201 South Street, Suite 300, Boston, MA  02111
Phone: +1 617 261 0264 ext. 133 | Mobile : +1 617 417 8989 | Fax: + 1 617 812 0330
jkamens@advent.com | www.advent.com
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Török Edwin wrote:

> Would you prefer freshclam/ClamAV crash/corrupt memory when loading the
> new databases with >980 byte lines?

No. I can think of ways around this to make things degrade
gracefully:

o The server could look at the Freshclam user-agent version number and
not serve up the new database if it's too old.

o The 0.96 Freshclam client could use a different request to get the
newer longer-lined files. (I guess it's a bit late for that now...)

> The initial announcement about this was 6 month ago.
> If a 6 month window to upgrade is not enough, what would be?

Nothing justifies a kill-switch. You seem quite naive regarding
real-world customers. Many of our customers are not very computer-savvy.
They can sometimes be hard to reach. And some of them have insanely
bureaucratic rules about how and when software can be upgraded...
we still have people who insist on running Red Hat Enterprise Linux 4
because they don't want to change.

I understand your frustration with people who take a long time to
upgrade. But a kill switch to force the issue is most unwelcome. It
also implies that anyone who somehow gets hold of your signing key can
kill every ClamAV installation throughout the world. :(

Regards,

David.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
>>>Would you prefer freshclam/ClamAV crash/corrupt memory when loading the
new databases with >980 byte lines?

If it was impossible to support new functionality with a database compatible with ClamAV <=0.94, then the database should have forked -- two sets of databases generated by the automated database build process, one containing only signatures compatible with ClamAV <=0.94, and the other containing all available signatures, and the database update infrastructure should have been enhanced to be smart enough to know how to download the correct database for the installed ClamAV version.

>>>The initial announcement about this was 6 month ago.
If a 6 month window to upgrade is not enough, what would be?

I'd say that obsoleting and remotely disabling mission-critical software that is less than two years old is unreasonable whether the software is commercial or OSS, and I'd say that doing so with anything less than a 1-year lead time is also unreasonable.

In comparison, Symantec says (see http://www.symantec.com/business/support/Symantec_Support_Policy.pdf), "We generally provide Support Services for each 'Major Release' of Licensed Software for a period of up to seven (7) years from the date it first became GA."

While seven years may be excessive for an OSS project, whose resources are obviously far more limited than those of a large corporation, I really think what was done here was excessive in the other direction.

Not to mention that y'all really need to put some thought into your version numbering. A major incompatible change like this warrants a major version bump, and yet despite the fact that ClamAV has been in use by many sites in production for years and years and you've introduced many major changes during that time, you're still not even at version 1.0. There's something wrong there.

jik
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/08/2010 12:05 AM, David F. Skoll wrote:
> Török Edwin wrote:
>
>> Would you prefer freshclam/ClamAV crash/corrupt memory when loading the
>> new databases with >980 byte lines?
>
> No. I can think of ways around this to make things degrade
> gracefully:
>
> o The server

You mean to do this on all the 122 mirrors here:
http://www.clamav.net/mirrors.html

> could look at the Freshclam user-agent version number and
> not serve up the new database if it's too old.
>
> o The 0.96 Freshclam client could use a different request to get the
> newer longer-lined files. (I guess it's a bit late for that now...)

How about 0.95? That version has been out for a while, and its not
affected by this bug.

>
>> The initial announcement about this was 6 month ago.
>> If a 6 month window to upgrade is not enough, what would be?
>
> Nothing justifies a kill-switch.

If the database is malformed .. ClamAV refuses to load.
This is what prevents malformed databases to be published by accident in
the first place.

>
> I understand your frustration with people who take a long time to
> upgrade.

We have 754868 signatures right now, out of those 626061 are .mdb
signatures.
.mdb signatures are not supported, and not loaded by some older ClamAV
versions.
Is it better if they keep running the old version, thinking they have
some anti-virus protection?

Best regards,
--Edwin
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/07/2010 1:10 PM, Török Edwin wrote:
> On 04/07/2010 10:31 PM, Marc Balmer wrote:
> > Am 07.04.10 21:29, schrieb Török Edwin:
> >> On 04/07/2010 09:21 PM, David F. Skoll wrote:
> >>> Hi,
> >>>
> >>> I have a question about the CVD that will "contain a special signature
> >>> which disables all clamd installations older than 0.95." What exactly
> >>> will this do?
> >>>
> >>> Will old versions always report "No virus"?
> >>>
> >>> Or will they always report "Virus?"
> >>>
> >>> Or will they always report an error?
> >> It will refuse to load the database and print an error message.
> >
> > even refusing to load existing signatures?
>
> "Will refuse to load" means that daily.cvd will be considered a
> malformed database by ClamAV <= 0.94.2.

That would be the case if it was actually downloaded.
Will the freshclam <= 0.94.2 actually download the updated signatures?

I think it won't and it will just spit out the warning message about
Upgrading details.

Then there really is no kill-switch, but signature updates simply
stop happening. This, along with the many other changes since 0.94.2
will drastically reduce the effectiveness of ClamAV to detect current
threats. That is what you get when you don't update.

Have fun with the consequences!

I could be wrong about how freshclam works though.

- Mark Pizzolato

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On Wed Apr 07 2010 22:47:27 GMT+0200 (CET)
David F. Skoll <dfs@roaringpenguin.com> wrote:

> OK. That's bad. Really bad. It's an enormous problem for us.
>
> We have some customers (I don't know exactly how many) who are
> running ClamAV <= 0.94.2. When this hits the ether, their mail
> servers will tempfail all mail because clamd will error out.
>
> This might even put us in legal difficulties: some of our customers
> have contracts with us in which we assert our software has no "kill
> switch" that can disable mail delivery. Thanks to the fine ClamAV
> developers, we've been shipping a kill-switch for years.

Do your customers use the public ClamAV mirror infrastructure?

If they do, and also use old ClamAV versions, they're (or will be)
making harm to our infrastructure and the other users of ClamAV who run
the latest releases. This is because the old versions of freshclam fail
to apply some incremental updates and need to download entire database
files as described in the original announcement:
http://lists.clamav.net/lurker/message/20091006.143601.d27bbd20.en.html

If they don't and *you* provide them with some private database mirror
(what you should really be doing!), then I see no problem - you can
simply keep redirecting (with some httpd rule or so) their installations
to a specific daily.cvd file which works for them until they get
upgraded to some recent release. We can't do that globally because the
diversity of software run by our mirrors makes this solution ineffective.

Regards,

--
oo ..... Tomasz Kojm <tkojm@clamav.net>
(\/)\......... http://www.ClamAV.net/gpg/tkojm.gpg
\..........._ 0DCA5A08407D5288279DB43454822DC8985A444B
//\ /\ Wed Apr 7 23:08:57 CEST 2010
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Török Edwin wrote:

> How about 0.95? That version has been out for a while, and its not
> affected by this bug.

Well, you don't seem to have any reservations about a kill-switch for
<0.95, so I don't see why you're suddenly so concerned about 0.95.
After all, everyone should be on the leading-edge immediately, right?

> Is it better if they keep running the old version, thinking they have
> some anti-virus protection?

Yes, it is better than a kill-switch.

Nothing justifies a kill-switch. Not in proprietary software and
not in free software. It simply shows a blatant disregard for your users
and is extremely unprofessional.

Regards,

David.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Mark Pizzolato - ClamAV-devel wrote:

>> "Will refuse to load" means that daily.cvd will be considered a
>> malformed database by ClamAV <= 0.94.2.
>
> That would be the case if it was actually downloaded.
> Will the freshclam <= 0.94.2 actually download the updated signatures?
>
> I think it won't and it will just spit out the warning message about
> Upgrading details.
>
> Then there really is no kill-switch, but signature updates simply
> stop happening. This, along with the many other changes since 0.94.2
> will drastically reduce the effectiveness of ClamAV to detect current
> threats. That is what you get when you don't update.

I would say that freshclam *should* refuse to download and "put in production" a
database that, if put in production, would prevent clamav from working. This
seems the Right Thing To Do even regardless of end-of-life problems.

In fact, this can be easily achieved even if the old freshclam cannot prevent
new "lethal" database from being downloaded: just change naming convention for
the "new" database and publish "new" freshclam that is aware of the new naming.
This way, old freshclam will not "see" the new database and thus the old
installations will not be "killed". Just slowly "starved" of new signatures.

That said, I mostly disagree with angry posters: I believe that antivirus
software upgrades should be treated the same way as security patches - urgently.
Delaying upgrade of antivurus software is as bad as delaying installation of a
security patch to your system. In both cases you stay unprotected against
freshly-emerged threats.

Eugene
Re: The upcoming 15 April kill-switch [ In reply to ]
On 07/04/2010 23.26, David F. Skoll wrote:
> Török Edwin wrote:
>
>> How about 0.95? That version has been out for a while, and its not
>> affected by this bug.
>
> Well, you don't seem to have any reservations about a kill-switch for
> <0.95, so I don't see why you're suddenly so concerned about 0.95.
> After all, everyone should be on the leading-edge immediately, right?
>
>> Is it better if they keep running the old version, thinking they have
>> some anti-virus protection?
>
> Yes, it is better than a kill-switch.
>
> Nothing justifies a kill-switch. Not in proprietary software and
> not in free software. It simply shows a blatant disregard for your users
> and is extremely unprofessional.
>

ask ms about windows xp :)


--
Gianluigi Tiesi <sherpya@netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/07/2010 08:33 PM, Gianluigi Tiesi wrote:
> ask ms about windows xp :)
>
There is no kill switch in Windows XP. Microsoft is ending support for
it, but existing installations of Windows XP will continue to work as
they always have for the indefinite future.

The parallel in the anti-virus world would be that even after Symantec
stops publishing updated virus definitions for an old version of one of
their anti-virus products, the last virus definitions published for that
version will continue to work for the indefinite future. They will
become less and less effective over time, but the product will continue
to do what it is intended to do at some level.

The parallel in ClamAV would have been if the maintainers declared that
they would no longer publish virus definition files for ClamAV 0.94 but
it would continue to work with the last virus definitions publish for it.

That is not what happened here.

That is what should have happened here.

jik

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch (and a feature suggestion) [ In reply to ]
Jonathan Kamens wrote:

> My company had hundreds of appliances in the field running versions of
> ClamAV affected by this change. When we saw the announcement, we
> immediately started working on figuring out how we were going to get
> them updated by April 15, and we succeeded in doing so.

We have hundreds of appliances too. Those are easy. Most customers
enable automatic updates and have long since upgraded, and those that
haven't are easy to find and to upgrade.

The problem is we have some customers who prefer RPM versions of our
software, and still others who install from source on platforms like
NetBSD, Solaris and FreeBSD. We have no administrative control over
their machines, yet if something goes wrong, they (quite reasonably)
call us.

So even though 80% or more of our user-base is fine, I still dread
hundreds of support calls come the 15th. It doesn't do *us* any good
to say "We told you to upgrade... why didn't you?" when some irate
caller's mail is down.

So anyway... to try to make something constructive out of this thread,
I have a feature suggestion: Incorporate the version number in your
DNS TXT records and download URLs. Your download mirrors can use
symlinks in most cases (when versions are completely compatible) and
you can easily stop older machines from attempting to download by
stopping updates on the 0.96.whatever.clamav.net TXT record.

Regards,

David.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Kamens, Jonathan wrote:

>
>>>>The initial announcement about this was 6 month ago.
> If a 6 month window to upgrade is not enough, what would be?
>
> I'd say that obsoleting and remotely disabling mission-critical
> software that is less than two years old is unreasonable whether the
> software is commercial or OSS, and I'd say that doing so with anything
> less than a 1-year lead time is also unreasonable.

+1

> Not to mention that y'all really need to put some thought into your
> version numbering. A major incompatible change like this warrants a
> major version bump,

+1


/Per Jessen, Zürich

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch (and a feature suggestion) [ In reply to ]
David F. Skoll wrote:
> Jonathan Kamens wrote:
>
>> My company had hundreds of appliances in the field running versions of
>> ClamAV affected by this change. When we saw the announcement, we
>> immediately started working on figuring out how we were going to get
>> them updated by April 15, and we succeeded in doing so.
>
> We have hundreds of appliances too. Those are easy. Most customers
> enable automatic updates and have long since upgraded, and those that
> haven't are easy to find and to upgrade.
>
> The problem is we have some customers who prefer RPM versions of our
> software, and still others who install from source on platforms like
> NetBSD, Solaris and FreeBSD. We have no administrative control over
> their machines, yet if something goes wrong, they (quite reasonably)
> call us.
>
> So even though 80% or more of our user-base is fine, I still dread
> hundreds of support calls come the 15th. It doesn't do *us* any good
> to say "We told you to upgrade... why didn't you?" when some irate
> caller's mail is down.
>
> So anyway... to try to make something constructive out of this thread,
> I have a feature suggestion: Incorporate the version number in your
> DNS TXT records and download URLs. Your download mirrors can use
> symlinks in most cases (when versions are completely compatible) and
> you can easily stop older machines from attempting to download by
> stopping updates on the 0.96.whatever.clamav.net TXT record.

I think the suggestion from Jonathan is a good one : allow people to
continue to run the antivirus with the older database and no updates.
That means, instead of "refuse to load and exit", it should just reload
the last valid database without update.

On the other hand, running an antivirus older than two years while there
are new releases available, for free, is quite irresponsible.

While it's acceptable to run a really old version of, say, openoffice,
it isn't for a security related software.

The problem with your customers is that you accepted to engage yourself
about something which is intrinsically moving and you have no control
(and you can't) just to satisfy the injustified inertia of a (I hope)
small amount of your users. Maybe you can set up a mirror on your
domain, with the old database, just for your lazy customers.

Regards,


--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr
Ecole des Mines de Paris
60, bd Saint Michel 75272 - PARIS CEDEX 06
mailto:Jose-Marcio.Martins@mines-paristech.fr
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 4/7/2010 4:05 PM, David F. Skoll wrote:
> o The server could look at the Freshclam user-agent version number and
> not serve up the new database if it's too old.
>

Wouldn't this provide a solution? I checked, and freshclam does provide
the version number in the User-Agent string. I used the trusty packet
sniffer to check first. And while I'm not sure what the end result/error
would be, couldn't the servers be easily configured to redirect requests
from old clients? Or better yet, somehow return the last valid/working
image for < 0.94.2 clients?

I understand that F/OSS projects like ClamAV are at the mercy of what
the developers would like to work on, and that generally means pushing
the code forward rather than maintaining past releases; but common
cutesy says they also shouldn't knowingly make technical decisions that
will result their code exploding into a burst of flames at some
arbitrary point in the future. As someone who regularly gets parachuted
into burning buildings with a keyboard and a water bucket; I
instinctively frown upon the people who go about setting fires on purpose.

There is a big difference between a product that is no longer
updated/maintained past a certain date but continues to provide the same
humble functionality it had when it was abandoned, and one that refuses
past a certain date.

Personally speaking, I have a few servers in production right now that
use 0.94.2 because moving past that point will require updating code to
use the new library interface. I had assumed on those servers that
ClamAV would simply continue working past the 15th, but would just be
stuck using whatever ends up being the last compatible signatures
database. This thread made me realize that if I don't disable freshclam
on the 14th, I might be needing the water bucket on the 15th.

For those sysadmins who don't notice this thread; I hope all that ends
up happening is inbound mail gets delivered without being scanned. And
that they are are able to revert their database to a working version or
update their installs before the bad guys realize which systems are no
longer scanning for viruses.

Of course the unlucky ones will only hear the bells that ring when the
bits stop flowing.

Anyone feel like volunteering to create a wrapped version of ClamAV that
is binary compatible with pre 0.95 installs?



_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
Hi there,

On Thu, 8 Apr 2010 T?r?k Edwin wrote:

> The initial announcement about this was 6 month ago.

It seems I missed that one. Can you point me to a link?

--

73,
Ged.
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
G.W. Haywood wrote:

>> The initial announcement about this was 6 month ago.
>
> It seems I missed that one. Can you point me to a link?

http://www.clamav.net/lang/de/2009/10/05/eol-clamav-094/

http://lists.clamav.net/lurker/message/20091006.143601.d27bbd20.en.html

http://lurker.clamav.net/message/20100208.165118.43d176f5.en.html


Best regards,

Nico


--

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch [ In reply to ]
On 04/08/2010 05:25 PM, G.W. Haywood wrote:
> Hi there,
>
> On Thu, 8 Apr 2010 T?r?k Edwin wrote:
>
>> The initial announcement about this was 6 month ago.
>
> It seems I missed that one. Can you point me to a link?

Initial announcement:
http://lists.clamav.net/lurker/message/20091006.143601.d27bbd20.en.html

Reminders:
http://lurker.clamav.net/message/20100107.135918.17d2f486.en.html
http://lurker.clamav.net/message/20100208.165118.43d176f5.en.html
http://lurker.clamav.net/message/20100407.141109.2a7c287b.en.html

Best regards,
--Edwin
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch (and a feature suggestion) [ In reply to ]
Hi there,

Le 8 avr. 2010 à 03:11, David F. Skoll a écrit :

> Jonathan Kamens wrote:
>
>> My company had hundreds of appliances in the field running versions of
>> ClamAV affected by this change. When we saw the announcement, we
>> immediately started working on figuring out how we were going to get
>> them updated by April 15, and we succeeded in doing so.
>
> We have hundreds of appliances too. Those are easy. Most customers
> enable automatic updates and have long since upgraded, and those that
> haven't are easy to find and to upgrade.
>
> The problem is we have some customers who prefer RPM versions of our
> software, and still others who install from source on platforms like
> NetBSD, Solaris and FreeBSD. We have no administrative control over
> their machines, yet if something goes wrong, they (quite reasonably)
> call us.

On some rpm linux, eg RH5 for example, there is yum. You can provide them a private yum server and this will done.
On FreeBSD, there is packages, same add a correct line into /etc/make.conf and portupgrade -pP will fix this for you.

> So even though 80% or more of our user-base is fine, I still dread
> hundreds of support calls come the 15th. It doesn't do *us* any good
> to say "We told you to upgrade... why didn't you?" when some irate
> caller's mail is down.

6 months for a security software is big. Do you forgot to upgrade your IOS or Firewall software ?
Clamav is security software, if you don't upgrade it, then... you have to be angry with you not author of free software like clamav.

/Xavier
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: The upcoming 15 April kill-switch (and a feature suggestion) [ In reply to ]
On some rpm linux, eg RH5 for example, there is yum. You can provide them a private yum server and this will done.

On FreeBSD, there is packages, same add a correct line into /etc/make.conf and portupgrade -pP will fix this for you.



How about you do us all a favor and cut out the patronizing?



Everyone involved in this discussion knows how automated package upgrades work. This is not the point...



6 months for a security software is big. Do you forgot to upgrade your IOS or Firewall software ?



The IOS and Firewall vendors provide safe, minimal upgrade paths to address security concerns. They support software releases for years. See, for example, the Symantec policy I referenced earlier in this discussion, which indicates that Symantec supports any software it releases for SEVEN YEARS after the next major version is released.



The ClamAV team cannot justify putting themselves in the same vote as "your IOS or Firewall software" unless they're willing to make the same kind of support commitment. But they don't. They put out new releases at least once per year and usually more than that, each new release contains substantial new functionality (and usually substantial new bugs to go along with it), and they don't issue security patches for old releases once new ones come out.



Clamav is security software,



Yes, it is, which is why it's all the more important for its authors and maintainers to provide reasonable upgrade paths to address security concerns for people and organizations who are not prepared to take the latest and greatest stuff within months after it is released.



Make no mistake, I think ClamAV is a nice package, I'm glad it exists, I'm grateful to the people who have put time and effort into creating, maintaining and enhancing it, and my company will continue to use it as part of our product's open-source platform. However, all of these things being true does not change the fact that I agree with David Skoll that the ClamAV maintainers sometimes show little regard for the real-world consumers of the package.



The plain, simple fact is that there are other ways this could and should have been handled.



Jik
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net