From: james.mailing at gmail.com (James Eaton-Lee)
Subject: Re: Software Licenses and compression (was:
	Multiple AV Vendors ignoring tar.gz archives)

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.

Powered by blists - more mailing lists