[IAEP] etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  After seeing that Jim Gettys and Alan Kay combined failed to
convince a guy on a software issue, it is uncertain that how much I
can add^^; But here goes:

At Wed, 25 Jun 2008 00:04:36 +0200,
Bert Freudenberg wrote:
> 
> 
> Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:
> 
> > The gist of the argument is that one can't currently know what's
> > really inside an etoys image, except beyond what it itself tells us,
> 
> This is indeed a valid concern. As I wrote before, an external tool  
> could be written to examine what exactly is in the image.

  Yes, and the argument seems to be going as if having these tools
externally would make some difference.  However, I think that whether
it is inside or not doesn't make any real difference.

  Frank, *all* bits in the binary image file is well-understood.  In
fact, we can open the binary file from an externally running program
(called InterpreterSimulator written in Squeak) and examine every bits
in the file.

  All bytecodes in the image file can be decompiled to human readable
text files and that could also be done externally; not exactly that,
but I once wrote such a thing.  (It was modified InterpreterSimulator;
wo it happened to be written in Squeak^^;)

  You can also "compile" all code by calling something like:

  SystemNavigation current allBehaviorsDo: [:cls | cls compileAll].

to make sure that the compiled bytecode in the image reflect the
source code text (the code for the compiler included).

  For knowing what bytecodes do and how fast it runs, many people have
been looking at the generated C code and assembly code for the VM to
make sure that the VM does the right thing.  (I mean many people.)

  Of course, one cannot prove that something (bad) would ever never
happen with any piece of software; Squeak probably has some
vulnerability, but we are not talking about vulnerability, but
intentionally put malicious code, yes?  We can (almost) assure that
nobody has spotted any intentionally put malicious code in the image
file.  And subsequent incremental changes are either in the form of
text change set, or some content.  A sizable community will make sure
that malicious code won't get in.

  I don't think Squeak's vulnerability is not particularly higher than
other language interpreters (it would be somewhat lower than most of
other scripting languages, as Squeak has somrestrictions on what you
can do with external C libraries.)  I can imagine a random analog
would be a situation where an email client is compromized and executes
the binary in an email it receives.  But you wouldn't reject the
client because of the vulnerability; rather you would fix it and use
it as an example of strength of open-source development, right?

-- Yoshiki