[Pkg-clamav-devel] remaining clamav bugs

[Scott Kitterman]

I know from the lunch I had last week that there is some upstream work coming 
in the next months on freshclam.  I don't know the details, so maybe this will 
end up resolved.

Scott K

On Friday, June 27, 2014 00:54:49 Andreas Cadhalpun wrote:
> 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
> 
> _______________________________________________
> Pkg-clamav-devel mailing list
> Pkg-clamav-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel