Re: oaklisp: contains 500kB binary in source
> If glibc binaries really had virus that were not it its source, and
> if that could have been avoided by more painful bootstrapping, would
> that mean clean oaklisp bootstrapping should not be required?
Right. And if my grandmother had wheels and a gas tank she would be
an automobile.
All new languages need a bootstrap path. People often write a
compiler for language L in L itself, for a variety of good reasons,
not least of which is "eating ones own dog food." Oaklisp is typical
in this regard: the Oaklisp byte code compiler and run time system are
written in Oaklisp. Therefore you need to have an Oaklisp system
available in order to rebuild the system from scratch.
As a convenience, someone ran the bootstrap process half-way and
included the results in the Oaklisp source package, to make porting
easier. But you are free to regenerate the system completely from
scratch if you so desire. You can examine the source for trojans, you
can examine the pre-built binaries, you can regenerate the pre-built
binaries, you can instrument the bytecode interpreter and check that
nothing unsafe is being done, you can verify the system to your
heart's content. You can write your own Oaklisp interpreter and use
it to run the Oaklisp compiler from source on itself and check if the
generated bytecode matches the pre-compiled bytecode included in the
source package; the source includes a interpreter and it would be a
relatively small matter to translate it from Oaklisp into RnRS Scheme.
All source is available: if you have any doubts at all you are ideally
situated to verify the system's integrity.
You might also want to check gcc and clisp and cmucl and various other
self-hosted language implementations and for trojans or other
integrity violations. This would make a nice technical report:
"Practical Experience with Integrity-Checking of Self-Hosted Language
Implementations" by Marco Franzen.
This is all, however, quite irrelevant to debian-legal. Many Debian
source balls contain derived files to ease building, such as
Makefile.dep or config.sub files. The situation here is no different.
--
Barak A. Pearlmutter <barak@cs.may.ie>
Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.may.ie/~barak/
Reply to: