full-disclosure - Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4207C84F.8040305@sdf.lonestar.org>
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Software Licenses and compression (was: Multiple
 AV Vendors ignoring tar.gz archives)

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.

                -Barry