Stephen Gran <[EMAIL PROTECTED]> writes: >> > Some various solutions have been discussed with upstream, but it is >> > up to upstream to implement one of them - I am not going to add the >> > code complexity as a Debian specific patch. >> >> Excuse me? The dlopen() patch I provided in #484670 for 0.94 is just >> over 30 lines[1], including comments, and affects only one .c and one >> .h file. There is really not _that_ much added complexity. And the >> patch has been tested for weeks here in a production setup. > > How big is your patch to make libclamunrar build standalone? Where > is it?
That is also attached to #484670. The clamav-unrar (0.94-1) source package provided there contains: * libclamunrar_iface/, with a trivial patch applied to its header file * libclamunrar/ (the code that had to be stripped) * autoconf infrastructure derived from the original clamav source (configure.in, clamav-config.h.in, config/, m4/ ...) * license files (LGPL, unrar) * A shell script that creates the clamav-unrar tarball from a pristine clamav tarball (tested with 0.94). libclamunrar and libclamunrar_iface are thus built standalone. I admit that I haven't thought about linking of the LGPLd libunrar_iface against libunrar. >> If we want to provide a solution that is helpful for our users, >> we'll have to provide it ourselves. Upstream is not going to do it. > > Please do some small amount of research before getting bent out of > shape. This is on the road map for 0.95, Ah, the joy of doing ... research in bugzilla. :-) You mean <https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1153>, I presume? > and last I looked, they were using an implementation based largely > around your patchset. Have you seen any actual code? There's nothing in trunk that I can see. "Done is better", not "Worse is better". ;-) > What I said, and what I mean, is that I am not planning on deviating > significantly from upstream in a security sensitive application that > is already hard to maintain through a stable release at the best of > times. While your patch is small, it introduces complexity that > isn't there now and has me maintain a new library in non-free. So > no, not just yet. Yeah, I see your point. You may as well strike the "security sensitive" part of your argument because the missing RAR support means that clamav misses many pieces of real-life pieces of malware that it would otherwise recognize. Worse, it flags them as OK. In my opinion, this gives users a false sense of security and they would arguably be better off if they were forced to download whatever upstream provides and install that without help from their distribution. That's what I meant when I wrote that dropping the package from the archive would be more honest. I suppose it does all come down to making some sort of tradoff. Just in case I hadn't stated this clearly enough earlier: My offering the dlopen() patch included and still includes an offer to help in maintaining the resulting package. Is "No, not just yet" going to be your final word on the issue regarding clamav 0.94? Cheers, -Hilko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
