I am sure we could go back and forth on and off list about these issues until we are blue in the face. There are many things below that are incorrect, assumptions or otherwise. I'm not going to respond to every bullet, but there are some that need to be corrected in order for perception to be corrected.
On 2/17/16 4:30 PM, Groach wrote: > Last response LABELLED IN BRACKETS for reference in my reply below > > On 17/02/2016 21:06, Joel Esler wrote: >> Let's try this inline-reply thing again, apologies for last time. >> >> On 2/17/16 12:15 PM, Groach wrote: <snip> >>> I am >>> also aware thatg it is multi-platform and that was the whole thing that >>> prompted my 'enquiry': the muti-platform consciousness seem to have >>> forgotten the impact that can be felt on Wiondows platform if you dont >>> take care. >> (B) ClamWin takes the ClamAV engine and repackages it for Windows. >> As I am >> sure you are all well aware. We can't monitor the forums/mailing lists >> of every subproject of ClamAV. I understand your frustration, but it's >> just not something I can feasibly do. > (B) Really, maximum of 5 minutes per DAY probably and only about 2 or 3 > official forums (if that). Not even needing responses from your team, > just your team to 'look in' to see if there is anything they should know > and learn about there own product (and mishaps). We put out a free engine, free detection, and we have full time developers dedicated to that free engine. Only the developers of the engine itself have ClamAV as their fulltime job. The signature writers are doing many more things, primarily, reverse engineering malware. <snip> > > >>> (D) Quote: "Not to say that your concerns aren’t noted, but generating >>> ClamAV detection is takes longer." >>> And this is the point of my mentioning it taking too long >> Understood. > (D) Acknowledged, understood but does it matter or change anything? > >>> Quote: "ClamAV should trust the certificate of the file (if you have it >>> installed correctly) and ignore those files " >>> Yes, but you cant. Clearly ASSUMING such 'safety measures' doesnt work >>> which brought peoples machines to their knees last week. An >>> alternative, safer approach is needed. >> (E) This problem (conviction of signed files) is exactly the reason we >> created the feature of Certificate Trust. I understand and comprehend >> what you are saying, I'm not ignoring you. But you have to understand >> that we expect ClamAV to work a certain way. We ship it with a >> recommended configuration, on by default, etc. What people do with it >> once it leaves ClamAV.net, we can't, and won't control. If you'd like >> to use a client that we make, Immunet is that suggestion. It has the >> same cost as ClamAV -- Free. >> > (E) If 'your certain way' allows the termination of windows systems and > services due to shoddy signature processes, then maybe it should be > reconsidered. (And yes, if its killing systems as it did, its a SHODDY > process). It isnt Clamwin or any window ports of Clam that are the > problem, it is the CLAM SIGNATURES that they all use (which is designed > by you and the point of contention here) I was unaware that we terminated Windows systems. Is this true? Were systems rendered completely inoperable? Why are we just now hearing about it? Seems like if it was such a huge issue that the developers of ClamWin would have contacted me directly, like they normally do. > >>> And the comedy value: >>> Quote: " would love to have more contributions from the community in >>> order to increase coverage." >>> You are not going to increase coverage whilst you ignore the workings of >>> windows, its flaws, its popularity and the sensitivity it has to your >>> signatures. Only by accepting these elements, and modifying the focus >>> on to them such as....: >>> >>> * better testing before release of signatures >> (F) Sorry you feel it was comedy. What, specifically, do we need to >> test >> against? I can see if we can't get those files added to the clean file >> repository that we do False Positive testing against before the rules >> are shipped. > (F) Before issuing a signature, TEST IT! Apply it to a dummy run of a > disk containing known windows and popular softwares. We do, against TONS of files, but this is my point against we can't test every file in the world. >>> * not assume all windows files are signed (genuine programs dont >>> necessarily come from Microsoft) >> (G) [a] Nor do we have a copy of every file that you *may* download >> on the >> Internet to test against. Again, I'm understanding what you are saying, >> but there are realities in play that are difficult to overcome >> completely. Like the ability to have every copy of every file that may >> be an FP, ever. > (G) Never said you need to against the worlds software. Also, I dont > know about writing signatures or whats involved. I do know that other > AV solutions have not been so catastrophic and that indeed sometimes > they can be a bit rubbish. What do they know that you dont? With that > in mind, I ask the question: What is worse a system infected with a > malware file or a system that wont run in the first place because the > slap-dash signature makers removed all standard genuine DLL's? However > you look at it, there must be tighter controls to avoid this happening > again. And without acknowledging this, and acting accordingly, then > there is no chance of it never happening again. They don't give their product away. > >>> * SPEEDIER response to FP's >> (H) Understood. Your concern is noted, is being addressed, and due >> to a >> recent large problem, we've had a backlog of things to catch up to. We >> apologize for the error. >> > (H) But I hope you are not suggesting slow response is due to recent > changes/projects within your team/structure? Response to FPs has been > slow (and often needing repeat submission reports over and over) for at > least 4 years Ive been using Clam. There are a ton of issues we've had to change since the original ClamAV team left. Part of that has been completely re-writing the entire backend of every. single. piece. of. ClamAV. From the infrastructure, to the website, to the mailing system, to the downloads. All, at the end, to provide a better experience. We appreciate your patience in the meantime. <snip> > > > Look, I am not here to argue and counter-argue - Ive been around long > enough to know that when a 'project' has been formulated, a plan of > action and methodology decided and procedures implemented, it is VERY > difficult for anyone outside of the project to suggest changes that will > be taken on board. (Principal, sometimes company rules and often > stubbornness prevents it). Im sure the quality of the signatures will > not change (despite a catastrophic example of why they should last > week), I'm sure the speed of them wont change (despite examples given of > malware that needs immunising and is over 17 months old, and Im sure > that voices like mine merely serve to strengthen the teams insistance > that "we are doing the right thing" and simply cannot stand on the > outside and look in and see another picture. (Heres a picture for you: > No other anti-virus software last week disabled entire windows systems. Again, /entire/ Windows systems? Seems like something we would have heard about immediately. > See (F) above. But thats ok, Clam are still doing things "right and the > only way they have decided to do it". Just as well CISCO do not apply > Clam's Quality Assurance to their company products otherwise the worlds > internet infrastructure would be crumbling. Incorrect. We do have QA staff, but for the engine. The signatures are automatically tested against known clean, but that is what I am saying, perhaps our "known clean" isn't big enough. <snip> We're always making improvements. We'll continue to get better. -- Joel Esler Manager, Threat Intelligence Team & Open Source Talos Group http://www.talosintel.com _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
