[Pkg-clamav-devel] remaining clamav bugs

[Andreas Cadhalpun]

Hi,

On 26.06.2014 22:13, Sebastian Andrzej Siewior wrote:
> On 2014-06-25 01:54:06 [+0200], Andreas Cadhalpun wrote:
>> Forwarded bugs:
>>   * #636881: waiting for upstream inclusion
> yes
>>   * #690788: waiting for upstream reply
>>   * #690789: waiting for upstream reply
> Those two look similar as both are about web downloads. I asked upstream
> to make them public. I have no idea what upstream did here but I guess
> nothing. The easiest way to close/fix both is probably to use libcurl
> for the download. I just browsed freshclam/manager.c which seems to do
> the work here and it looks like they implemented everything (includung
> proxy support) more or less from scratch.

I guess the only reason for writing from scratch is that it has 
historically grown from very simple HTTP functionality step by step to 
what it is now, and at each step it seemed easier to add a little bit of 
functionality than to switch to using a library for that.
But now that clamsubmit already uses libcurl, it would be a bit more 
sane to use libcurl for freshclam as well. This would probably also 
prevent future problems. It just seems to be quite a bit of work.

>>   * #740059: waiting for upstream inclusion
>>      None of the forwarded bugs are publicly accessible.
>>      So has there been progress on any of them?
>>      Maybe we should create an account for the pkg-clamav-devel list and
>>      add it to the CC list of all these bugs.
> But then you still can't login and comment unless we share a common
> login. I just asked upstream to make it public.

That's indeed a problem with my idea.
Another problem would be that if upstream really wants to keep the bug 
private, it wouldn't be nice to forward comments to a public mailing 
list... so scratch that idea, it was a bit late, when I came up with it.
Asking to make the bugs public is a better way.

>>   * #295547: TODO: update patch -> ping upstream
> Yes, we could do that. In case nothing happens we could close this since
> the reported said he does no loger care.

Well, the feature seems useful and there is a patch. I don't think it 
would be too difficult to update the patch. The biggest issue is likely 
that nowadays clamd_connect uses negative return codes, which is checked 
for, so one can't just switch to 9X return codes.

>> Outstanding bugs:
>>   * #636877: blocked by 636881
> So the best case scenario is once we get 636881 fixed, we can think how
> we get that files removed on update :)

We could just remove it in the postinst script, but we should probably 
add a NEWS entry about that, so that users can migrate their 
configuration to clamav-milter.conf.
By the way, I noticed you added a 'exit 1', when $User is not set.
To comply with LSB status codes this should be something like:
   if [ "$1" = "status" ]; then
     # program or service status is unknown
     exit 4
   else
     # program is not configured
     exit 6
   fi

>>   * #675558: TODO: Can clamav be made to use the system libmspack?
> oh yes. This looks like fun. I think yes it should work. The purpose /
> required functionality is the same.

The problem is just that the API of the system libmspack seems to be 
completely different...

>>   * #393258: Should we split clamdscan from the clamd package and make
>>              clamdscan only recommend clamd?
> It makes sense for the scenario mentioned.

That was my impression as well. So I think we should follow up on 
#393258 to discuss the implementation details.

>>   * #530520
> The mail mentioned in bug report is probably
> http://archives.neohapsis.com/archives/postfix/2008-08/0797.html
> It looks 100% harmless. The fix would be either for postfix not to open
> a connection before we have the hostname (which makes me wonder why do
> we need to resolve the hostname at all). The simpler way would be to drop
> the message about host unknown.
> We could add a reference to this email explaining the situation, drop
> the check (or the resolve of the hostname in case it does not matter)
> and see how upstream reacts.

I had the impression that this is rather a corner case issue. But if you 
think it's worth doing something about it, we sure could come up with a 
way to handle the 'unknown' hostname.

> , #529986: What do you think about these?
> Sounds usefull however I am not sure how many people care about his. The
> popcon stats is quite low.

We could ask if Martin Krafft still cares (and if he would write a 
patch). It should just need some check in clamav-milter/clamfi.c.

>>   * #234926: Wait for reply. Without that, close the bug.
>
> He does not care about his anymore, the initial usecase is no longer
> valid.
> It would be nice to have the same timestamp but it adds actually no
> value. If we pull-in libcurl then we get mostlikely the correct
> timestamp for the complete cvd file downloads. And the problem remains
> probably for the case where the cvd file is an incremental update.
> I would say we close this sice Marc no longer cares and the added value
> has no meaning to anyone.

So let's just wait a week or so and then close the bug.

Best regards,
Andreas