ClamAV is not the only project we run. When you all (or we) discover an issue, I take that information, file a ticket with our operations team, and the issues are resolved as we get to them, just like any other infrastructure. Not only do we run ClamAV, but we run Snort, and entire Talos infrastructure. With the same ops team.
Right now, 99% of the work with ClamAV is behind the scenes with the system that generates and publishes signatures. Since we re-wrote the entire system, we've had a couple issues on the backend, and we've been fixing them as they come along. However, we have a major issue right now with the simultaneous amount of signatures that we can input into the system, and we are working on this. As for the blog, it's on http. There's nothing that needs to be encrypted there, its just a news outlet, and we have no need of making it http. The blog is hosted on blogger.com, which does not allow https, so in order to encrypt the traffic, we'd have to move to a different blog infrastructure. Something I have no interest in doing at this time, or in the foreseeable future. The blog is for news. It can stay unencrypted. We'll take a look at the rest. Lists is hosted by us, and we can fix that. I'll file a ticket. I already have a ticket in for the bugzilla https issue. Sent from my iPad > On Dec 11, 2016, at 7:45 PM, timeless <timel...@gmail.com> wrote: > > Reindl Harald wrote: >> don't matter - instead of writing a mail that should have been just fixed > > I'm pretty sure the author was "filing a bug report" and not in a > position to fix it... > > I'd hope that user MLs would not be particularly hostile to users > reporting things that need to be fixed... > >> it's not rocket science to deploy SSL certs which match the used hostnames, >> at least not when it takes a few seconds to pase a vhost config and verify >> if all the names are listed in the cert while the main question is why a >> vhost needs that much names at all instead "THAT is the name of the >> subdomain and THAT is the certificate for it" > > Eh. Getting this stuff right isn't necessarily rocket science, but it > often isn't as easy as one might expect. > Split horizon dns servers come to mind. I haven't looked at forwarding > proxies yet, but, ... > > Certainly, if a server is configured to only offer a single service > (not unreasonable), it isn't enough for it to know its own hostname, > it also needs to know all legitimate dns records that might point to > it. > > (And the person maintaining a server/service isn't necessarily the > person who maintains DNS.) > > Actually having a script to validate this seems useful. > > FWIW, to make this email more useful, it'd be nice if: > 1. https://blog.clamav.net worked (there's currently no server > listening on :443, so when someone goes to fix bugzilla's server, if > they could consider issuing a blog cert and enabling it for blog, > that'd be nice). > Also, unlike blog: > 2. lists.clamav.net seems to have half of a server on :443, it's > listening, but not answering. It'd be nice if someone fixed it to > answer. > > Assuming one has a friendly ns server (i.e. what I'm going to be stuck > doing sometime soon), one basically wants to query the name server > using dig ANY server and then run curl -sS https://{hostname} > > /dev/null > _______________________________________________ > clamav-users mailing list > clamav-users@lists.clamav.net > http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
