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 > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
