Full Disclosure mailing list archives
Re: Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives)
From: James Eaton-Lee <james.mailing () gmail com>
Date: Tue, 08 Feb 2005 00:37:06 +0000
On Mon, 2005-02-07 at 14:58 -0500, bkfsec wrote:
James Eaton-Lee wrote:Add to this the fact that implementing archive support in an antivirus package isn't as simple as it might seem; although bz2 is released under a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor would have to write their gzip code totally from scratch.Now this is a non-sequitor. It's a non-sequitor for two reasons: 1) It's irrelivent and 2) It's wrong. First, it's irrelivent because if this is a percieved weakness of an antivirus package (and I can see how someone can see it as undesirable under certain conditions, though not all conditions) then its implementation isn't the concern of the reporter. We know that it can be done and, if it's of high enough value, it should be done -- irregardless of whether they get the code from a third party or write it themselves. Second, it's wrong for a couple of reasons. Yes, they would not be able to take GNU gzip and implant the code into a proprietary application. However, that does not bar them from utilizing and distributing GNU Gzip with their application. If they were to wish to use GNU Gzip, there are ways that they could engineer that into their product without causing licensing issues. They could simply use gzip/tar to gunzip/untar the package as a stream and pass that into their preprocessor for analysis in their sandbox. That would require no cross-polination of the licenses and would leave the third party software intact. These kinds of arrangements are actually quite frequent in the world of software design. Further, it's not like the gzip compression algorithm of some kind of guarded secret proprietary protocol. It's a standard protocol and there are a number of proprietary implementations that could be licensed for use in proprietary programs. In either case, including third-party software into a security product can be a gambit and, as such, that code has to be heavily audited in order to be included into the software suite. Or, at least, it should be heavily audited. Anyway, they wouldn't be able to just take bzip2 and place it directly into the source of the AV system either. Interfaces have to be crafted and tested, in order to be consistent. You also have to take into account differences in the programming environment for the AV/Compression scheme and optimizational concerns. In the end, your point in trying to differentiate the GNU GPL from the BSD license here is completely and totally moot. It does nothing but predicate misunderstandings concerning the GNU GPL and further cloud this potential security issue.
I wasn't trying to cloud the issue at all, nor was I specifically trying to differentiate between the two - the paragraph you've just dissected directly followed a statement about the relative lack of speed which implementing archive support in an anti-virus package would necessitate vs. simply writing a new antivirus definition, and the reference to GPL and BSD software was preemptively negating a response along the lines of 'they could simply incorporate X source code'. I fully understand both the distinction between the two licenses, how they can be implemented into a proprietary product, and the testing involved in incorporating someone else's source code into a large codebase - again, my point was that whether implementing gzip/bzip2/X support in an antivirus package is hard or not, it is a reactive measure which antivirus vendors do not (and should not) have to take, since unlike antivirus definitions (which are necessarily written reactively), compression support is easily integrated into a package - with forethought - and prevents such issues further down the line; further to that, I also argued that it would be silly to reactively implement compression support not only because it's unnecessary, but also because it would (as you have in fact agreed with me on) be harder to implement this support into an anti-virus scanning engine even if, as you say, this is a "standard protocol". So I think you agree with me, really; thankyou for your e-mail! :) - James. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: Multiple AV Vendors ignoring tar.gz archives, (continued)
- Re: Multiple AV Vendors ignoring tar.gz archives Barrie Dempster (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives Paul Laudanski (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives Barrie Dempster (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives Nick FitzGerald (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives James Eaton-Lee (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives Nick FitzGerald (Feb 05)
- Re: Multiple AV Vendors ignoring tar.gz archives James Eaton-Lee (Feb 06)
- Re: Multiple AV Vendors ignoring tar.gz archives bkfsec (Feb 07)
- Re: Multiple AV Vendors ignoring tar.gz archives James Eaton-Lee (Feb 07)
- Re: Multiple AV Vendors ignoring tar.gz archives bkfsec (Feb 08)
- Re: Multiple AV Vendors ignoring tar.gz archives James Eaton-Lee (Feb 05)
- Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives) bkfsec (Feb 07)
- Re: Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives) James Eaton-Lee (Feb 07)
- Re: Multiple AV Vendors ignoring tar.gz archives Rodrigo Barbosa (Feb 10)
- Re: Multiple AV Vendors ignoring tar.gz archives Jorrit Kronjee (Feb 10)
- Re: Multiple AV Vendors ignoring tar.gz archives James Eaton-Lee (Feb 11)
- Re: Multiple AV Vendors ignoring tar.gz archives Nick FitzGerald (Feb 07)
- RE: Multiple AV Vendors ignoring tar.gz archives Nick FitzGerald (Feb 07)
- RE: Multiple AV Vendors ignoring tar.gz archives Barrie Dempster (Feb 08)
- RE: Multiple AV Vendors ignoring tar.gz archives Nick FitzGerald (Feb 08)