Does anyone know where there is a CLS v6.0 equivalent of ftp://ftp.nai.com/pub/datfiles/english/dat-5804.tar ?
Any help would be appreciated.
Thanks for that link Rod, but unfortunately not many of the Unix systems I'm trying to deploy to have zip installed as standard. That was a problem I already encountered at v5.3 but I got round it by using the .tar file - there just doesn't seem to be a corresponding .tar file for the avv files.
If I can't get a .tar file, it looks like the only option will be to revert back to CLD v5.3 which I think is a shame.
Hmmmm... unfortunately there aren't any plans to post avvdats in .tar format far as I'm aware. Sorry about that.
As a workaround, you would need to expand the zip manually and then then rebuild it as a tgz. This should work without issue.
Something else to be aware of: the old style DATs (known as V1 Dats) will be out of support in March 2010 - so its a good idea to start planning for accommodating the new V2 Dats as early as possible to avoid headaches when you're forced to do it!
To find out more about V1 and V2 Dats, go to the McAfee ServicePortal and search for KnowledgeBase article KB60404 – End of Life for products using version 1 DAT files (Names.dat, Scan.dat, Clean.dat).
Hope this helps!
Thanks again Rod, that is very bad news indeed!
For Command Line Scanner for Unix, the Unix clients need the DAT package in tar format, not zip, as Unix generally does not support unzipping multi-file zip format (maybe Solaris does, but AIX doesn't and HP-UX doesn't) out of the box.
If you say v1 DATs are not going to be supported from March 2010 (I read Dec 2009 somewhere), then we need to go to CLS v6.0 and use v2 DATs as you say, but if you can't supply v2 DATs in tar format then that's the end of the road for us. This has to be an automated solution and "manual" unzipping is not an option. We could conceivably use a Windows client to host the DAT files for us, but that seems to me to be an unnecessary extra step to take, when you could easily put the v2 DATs up on the FTP site in tar format as you currently do for v1 DATs. Using a Windows client in this way also introduces a serious SPOF into our design and we would prefer to use the ftp.mcafee.com service.
My best advice to you at this point would be to raise a case with McAfee techincal support. This way we can properly track these types of issues and requests, and those bright-sparks may be able to find some way to workaround this issue.
Please let me know how this goes - (either via the community or PM me).
Not sure if this is an option on your environment, but on this page you will find ports of UnZIP for nearly all Unix platforms:
You will see a mention to CVE ID CAN-2005-2475 in there but to the best of my knowledge that vulnerability only concerns deliberate misuse by a local user, no idea if there is any way to exploit it remotely...
Hopefully this helps
Thanks Marcelo, that information will be useful if a) I can't get the avvdats is tar format and b) the race condition issue is resolved and the downloads are un-frozen.
However, I really would rather McAfee made the v2 DATs available in TAR format because it seems to make so much more sense McAfee making one change (which it used to for the v1 DATs) rather than forcing every one of its clients to install new and untested software.
I have taken Rod's advice and raised a ticket but am still waiting for a response.
Is there anyway for us to be warned in advance about these types of changes? A mailing list of some sort? It's unacceptable for us to have our virus scan updates to suddenly stop working, we need to be able to plan around this.