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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1078173501.4293.17.camel@coruscant.weisserth.net>
From: tobias at weisserth.de (Tobias Weisserth)
Subject: The Trillian GPL violation allegations are
	confirmed false.

Dear Valdis,

Am Mo, den 01.03.2004 schrieb Valdis.Kletnieks@...edu um 19:20:
> On Sun, 29 Feb 2004 01:54:51 +0100, Tobias Weisserth <tobias@...sserth.de>  said:
> 
> (Note - although my name got dragged into this, I'm not at all privy to what
> the actual Trillian code looks like... I just contributed a Gaim "off by one" fix that
> happened to be in the code section in question).
> 
> > Question: If Cerulean Studios let GAIM use parts of their codebase, how
> > can the GAIM people license this under the GPL?
> 
> Because I'm told they shared *algorithms*, not actual code.  And copyright
> and GPL don't enter into it.

There is rather strong evidence the code is too similar to be based on
the same abstract algorithm only. I gladly forward you to the issues
Stefan Esser has already investigated.

> "What you need to do is loop across the packet while doing this..."
> 
> You might still have patent or trade-secret issues, but there's no copyright
> issue at that point.

If indeed no code has been shared. But this I believe. See below.

> > There are enough clients that can connect to the Yahoo network and which
> > haven't been vulnerable to the GAIM exploits (which were buffer
> > overflows mainly if I remember correctly). 
> 
> If the shared algorithm had a bug (such as "oh, and don't forget to do this")
> then of course both implementations will be broken.

Abstract algorithms do not have real-world exploitable buffer overflows.
Real-world implementations of abstract algorithms do have buffer
overflows. I just can't believe the "coincident" explanation of two
similar implementations when there are virtually a dozen other ways to
do it and even do it better.

> Bugs can creep through even the best Chinese-wall development - if the original
> has a bug, the team doing the reverse engineering will probably have the bug in
> the specs that get handed across the wall, and as a result the code written
> will be bug-compatible.

See above. Please give an example of an abstract algorithm (maybe in
pseudo-code) that contains a real-world exploitable buffer overflow.
This is only possible if this abstract algorithm already has been
described in a real language, say C# and that makes it more than just an
abstract algorithm, it makes it C# source code.

> At a previous gig, a co-worker of mine wrote an emulator for a Tektronix 4027
> graphics terminal to run on a Zenith Z-100.  Working only from published specs
> and "what does a real 4027 scribble on the screen" he found his program
> produced different results for certain color-fill operations with some complex
> self-intersecting polygons - which he tracked down to a bug in the 4027
> firmware, and then reproduced in his software to be bug-compatible.  All without
> access to any proprietary Tektronix information....

I fail to see how this incident relates to the GAIM/Trillian
"coincident".

To be absolutely clear about my intentions and why I'm that interested
in the matter: I don't care who gave code to whom. But I want it
properly documented, at least in the GPL GAIM sources that are available
to the terms of the GPL to other developers. Suppose someone uses the
GAIM code in another GPL project and years later someone from Cerrulean
Studios turns into some Darl McBride and starts crying out loud. How is
this forked GPL project to defend against future claims if they can't
rely on a clear documentation in the GAIM sources where their code came
from? Maybe right now nobody from Trillian is claiming GAIM somehow
released code under the GPL without permission from Trillian but suppose
years later someone from Trillian does?

This is a risk issue. In the interest of the usability of the GAIM code
under the GPL it has to be documented clearly and without a doubt where
which code came from under which terms.

The "coincident" creation of the code is not really believable. When
there's supposedly no problem involved here then why do I have the
impression that people are not honest about the sources?

kind regards,
Tobias Weisserth


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ