> 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 <[EMAIL PROTECTED]> Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
