Re: GNU FDL 1.2 draft comment summary posted, and RFD (fwd)
On Thu, Jun 13, 2002 at 04:22:18PM +1200, Nick Phillips wrote:
> On Wed, Jun 12, 2002 at 11:40:44PM -0400, Anthony DeRobertis wrote:
> > It is much easier for me to --- for example --- hide an exploitable
> > buffer overflow in Apache than it is to hide something in a document.
>
> It's clear to anyone who bothers to examine the source code that the elements
> you are talking about are insertions and perform functions other than that
> for which the whole thing was intended.
No, this is not the case. Buffer overflows are damn hard to detect, that
is why they still show up in some programs after years of public auditing.
If one were to deliberately introduce a buffer overflow, it could be
done with very subtle changes, each of which looks innocuous and
straightforward. Probably all of the changes could be presented
as efficiency improvements. If one desires less subtlety, it is easy
to add a small new feature that contains a security hole. It is in
fact so easy that people tend to do it by accident.
> > No. Much easier, as I pointed out with Apache above. Security holes are
> > one very well known example, though they are usually mistakes. Ken
> > Thompson has a paper about trojaning the compiler ;-) See:
> > http://www.acm.org/classics/sep95/
>
> Zzzzz... anyone who reads and understands the source will notice any added
> backdoors, even without seeing the original.
I guess you did not read the referenced paper :)
The whole point of that trojan was that it would be _invisible_ to anyone
who looks only at source code. It hides in the compiler executable, and
only activates if it notices that it's compiling another compiler.
This attacks the fundamental weakness of "compile from source" virus
protection: at some point you need to trust a compiler. Hardly anyone
starts from scratch anymore, even when bootstrapping a new architecture.
Of course, such code is likely to be eventually destroyed by mutation.
Surviving the gcc 1.x to 2.x transition would have been quite a feat.
> Not true with a document, as
> documents' original purposes or results are less likely to be well-known or
> even well-defined.
This holds true for editors as well as for readers.
[...]
> If they then try the product and find that they
> have wasted their time and effort, then they are just as likely to think
> badly of me as of the later editor, unless the later editor is required
> to make clear that the final document is likely not a fair representation
> of my thoughts, experiences and conclusions.
How is the later editor to know whether or not this is likely?
You assume that such an unfair representation is going to be deliberate.
I think it far more likely that it will be accidental; and in any case
someone who seeks to deliberately twist your words is not going to pay
much attention to your license.
I think this boils down to a requirement for a stronger notification
than just "this document is derived from that document". Perhaps
add "... and is not necessarily a fair representation of the thoughts,
experiences, and conclusions of the original author"?
I personally think that goes without saying.
Richard Braakman
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: