Re: [IAEP] etoys now available in Debian's non-free repository
On Saturday 28 Jun 2008 8:05:41 am Alan Kay wrote: The sources and changes files (the changes are the incremental history to the sources) don't have to be external to the image, but they have been made so since Smalltalk started to be implemented on computers that had fallen back to the bad old idea of operating systems and file systems. This is easy to find out about in a variety of ways. But there is something further to ponder about this method from the 70s. And that is the idea that as scaling advances under Moore's Law, it will be less and less a good idea to rebuild from scratch (and more and more difficult). Well, there will always be people who will seek to build (or trace the path of evolution) from scratch, if only to study how the whole thing evolved. Others may want to study a suspended image to see what is in it and how it managed to get into such a state. Some people just choose to become archaeologists, paleontologists and even pathologists. For those who have been working with live images for decades, this direction of learning may not be of interest, but it would help if they can point out the way and let others make their own journey. Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
P.S. Re: [IAEP] etoys now available in Debian's non-free repository
P.S. I thought of a different way to possibly resolve this. It occurs to me that this discussion and differences of opinion could really be about how executables are made. One of the main issues cited has to do with security, and a notion that being able to see the sources will help. The simplest application model today has a file which contains executable code and one or more files of non-executable data which is manipulated by the executable file when they are combined into an OS process. For example, a text editor in Linux will have a file of executable code and a file that is a text document that (presumably) has no executables in it. Since (Squeak) Smalltalk is set up to run under various OSs (even though it doesn't need them), this model is followed. There is an executable file which contains all the executable machine code in the system -- it usually has a name like Squeak.exe -- and there can be any number of document files which contain only data. The image file is such a document file, and it contains no executable code wrt any computer which might use it -- it is a pure data structure. Squeak.exe or its equivalent is ultimately made by (a subset of) the C compiler and tools of the operating system that will: invoke it, give it access to the screen and keyboard and file system, etc. Every piece of C code that is fed to the C compiler is on one file or another and available for perusal. In practice, we don't write most of this code by hand, but generate it from a higher level architecture and debugging process that is internal to the Squeak system. But still, the result is C code that is compiled by someone else's C compiler (in this case one of the Linux compilers) into standard Linux executables that will be run in a standard way. Any Linux person can examine all the source files using tools they are familiar with. The executable file is like an OS kernel that can incorporate executable plugins -- for graphics, sound, the particle system, (Mozilla has even been run as a plugin, etc.)), so there can be lots of stuff in this file -- but again, all of it ultimately has to be made in a form that is acceptable to the underlying OS which owns the machine resources. Seems as though this should do it. And all these files are readily available for all of the OSs we deal with. We would build the Squeak kernel very differently if there were no OS to contend with or that has to be cooperated with But, since we don't regard ourselves as a religion or the one right way, we are content to go along with current conventions where the alternative is needless argumentation. The rest of the misunderstandings seem to me to be epistemological, and ultimately go back to very different POVs taken by different research groups in the 60s. From several different motivations, the ARPA (and then the PARC branch of ARPA) community got into thinking about highly scalable architectures, partly motivated by the goal of a world-wide network which had to scale better than any computer artifact by many orders of magnitude. This community also took Moore's Law seriously, particularly wrt personal computing and just how many nodes the proposed network might have. This led to a no-centers style which manifested itself most strongly in the 70s. The most extreme successful versions of this style eliminated the OS, file systems, applications, data structures, simulated punched cards/teletype, etc., in favor of what Marvin Minsky called a hetarchical (as opposed to hierarchical) organization of as much as possible. Several of the formulators of this style had considerable backgrounds in biology, whose no-center scaling then and now goes far beyond anything successfully done in computing. It was realized that most computing of the 50s and 60s was rather like synthetic chemistry in which structures are built atom by atom and molecule by molecule. This gets more and more difficult for larger and more complex combinations. Life generally uses a process quite different -- instead of building cells and organisms, it grows them. This leads to seeming paradoxes in the epistemology of making -- i.e. to make a cell we need a cell., to make a chicken we need a chicken. However, all works fine in the epistemology of growing. But the initial bootstrapping is a little tricky. Once the bootstrap is done to make life then life can assist much more powerfully in making more life, and to vary life, etc. As mentioned before, the Internet is one of these, and so is Smalltalk. In biologically inspired architectures one is much more interested in how the organism and ecologies of them are to be sustained, and how the dynamical systems can be understood, fixed, changed, evolved, reformulated, etc., while they are running and with the help of tools that work within them. Just as a cell, and especially e. g. a human baby, is not made by hand, we are more interested in making growth
Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository
On Sat, 2008-06-28 at 04:21 -0700, Alan Kay wrote: It was realized that most computing of the 50s and 60s was rather like synthetic chemistry in which structures are built atom by atom and molecule by molecule. This gets more and more difficult for larger and more complex combinations. Life generally uses a process quite different -- instead of building cells and organisms, it grows them. This leads to seeming paradoxes in the epistemology of making -- i.e. to make a cell we need a cell., to make a chicken we need a chicken. However, all works fine in the epistemology of growing. But the initial bootstrapping is a little tricky. Once the bootstrap is done to make life then life can assist much more powerfully in making more life, and to vary life, etc. As mentioned before, the Internet is one of these, and so is Smalltalk. In biologically inspired architectures one is much more interested in how the organism and ecologies of them are to be sustained, and how the dynamical systems can be understood, fixed, changed, evolved, reformulated, etc., while they are running and with the help of tools that work within them. Just as a cell, and especially e. g. a human baby, is not made by hand, we are more interested in making growth processes that can be influenced with far more ease than direct construction. So, most objects are made by other objects acting under conditions that include the dynamic state in which they will become part of the ecology. It seems to me that this analogy is a fairly good one -- although there are definite differences, in that the 'cell' needed to make another 'cell' in the etoys/squeak case has been designed with lots of tools to make it easy to inspect and modify itself, as well as to completely sequence its DNA or produce a new generation on demand. Living systems are however notorious for carrying historical baggage along with them in their genotype, and, since the phenotype cannot easily be recreated without starting with a parent phenotype, the Ken Thompson hack implies that inheritable baggage can (paradoxically) be carried in the phenotype as well. I think the number of somewhat independent tools provided to in[tro]spect a running image would make an intentional malicious Thompson hack in Sqeak quite difficult to maintain for long without discovery; but I would naively guess that there is some 'harmless' baggage that looks reasonable and is allowed to continue just due to inertia. Since the 'DNA' (source code) of etoys/squeak is readily available in a transparent, human-understandable form, it seems to me that the only issue of possible concern is the lesser visibility of the 'paradoxical' inheritance via phenotype/image. Or at least, its lesser visibility if one refuses to run etoys/squeak to use the tools it provides to inspect itself or its images. Continuing with the biological analogy, the folks who want to be able to bootstrap a Squeak/etoys image (starting from 'scratch' without such an image) want literally to be able to make ontogeny recapitulate phylogeny -- not necessarily every time an image starts, possibly not necessarily every time Squeak is 'built' -- but at least with similar frequency and the ease of bootstrapping gcc using a different C compiler. (Like using a turtle egg to hatch a dinosaur ;-) I don't have a strong opinion on this myself, but I do find the discussion interesting. - Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository
Continuing with the biological analogy, the folks who want to be able to bootstrap a Squeak/etoys image (starting from 'scratch' without such an image) want literally to be able to make ontogeny recapitulate phylogeny -- not necessarily every time an image starts, possibly not necessarily every time Squeak is 'built' -- but at least with similar frequency and the ease of bootstrapping gcc using a different C compiler. (Like using a turtle egg to hatch a dinosaur ;-) I believe that the question is not whether a system can do it or not. Smalltalk-72 did it, GNU Smalltalk and Scheme 48 do it, and our fonc project is right now taking similar approach. So bootstrapping is possible. However, given the current status, the trade off between having to change the existing system fundamental way and its value is the question. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository
On Saturday 28 Jun 2008 4:51:47 pm Alan Kay wrote: It was realized that most computing of the 50s and 60s was rather like ... state in which they will become part of the ecology. I propose that this overview be included as part of Squeak. Squeak is very different from conventional programming toolkits. A good overview like this would help set the right perspective at the beginning and eliminate many misunderstandings down the road. Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
The analogy doesn't work. If I have C, I'll send the C. I have friends who used to write APL and ship Ada as source, and their military customers never complained. If the generated C is well-structured and has the comments from the Smalltalk embedded, so that people can understand it, what's the problem? What happens if I make my changes to that generated C and then try to submit those changes to the generated code back to the Squeak project? I think this is what Yoshiki means when he says: if you send them C that's generated and call that your source, it's the same thing as writing your code in C and sending assembler as your 'source' (assuming there was a cpu independant assembler) Free software is also the freedom to develop code with the source you are supposed to have access to. Otherwise you may have gotten some of the things that are necessary for software freedom, but you do not have all the things that will make it sufficient for you to have actual living breathing farting software freedom. Kind of like how freedom of speech may be a necessary part of political freedom but just because a politician is not messing with that freedom does not mean that s/he is not putting all the other sufficiencies for political freedom into the smoothie blender. PLUR kiddies and shout it out for all to hear: Smalltalk inspect. - antoine ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 27, 2008 at 10:17:54AM +0200, Antoine van Gelder wrote: The analogy doesn't work. If I have C, I'll send the C. I have friends who used to write APL and ship Ada as source, and their military customers never complained. If the generated C is well-structured and has the comments from the Smalltalk embedded, so that people can understand it, what's the problem? What happens if I make my changes to that generated C and then try to submit those changes to the generated code back to the Squeak project? I think this is what Yoshiki means when he says: if you send them C that's generated and call that your source, it's the same thing as writing your code in C and sending assembler as your 'source' (assuming there was a cpu independant assembler) Free software is also the freedom to develop code with the source you are supposed to have access to. ...and the deroute through C does not conflict with that freedom. The freedom to develop based on the provided source is what we call forking. You are talking about the ability to give back to the original community, which is a different thing. If I develop based on the source provided by Linus Torvalds (the Linux kernel) and want to give back to the original community my changes, then they will get rejected if I do not follow their coding style and their way of commiting patches. If I understand correctly, the Squeak community accepts patches generated from their binary images. So the real question is, if images built from C sources can generate patches acceptable by the Squeak community. I honestly do expect Debian to approve Squeak if such C decompiler is invented. And I imagine the Squeak community will support it too, if recompiled code generates images workable with them (rather than working as a slight fork). Hope I made sense here - I am _very_ new to the Squeak concepts, following these discussions as part of my packaging Sugar software officially for Debian. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhkq4MACgkQn7DbMsAkQLjptQCgns8VuwXTa4hqrICtcUA2gPGU r/AAn1iAK9KwAy9i+WmMumfawwUNfzQ3 =eFlz -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
To: all the parties who are worrying about this ... Given the history (not just PARC but going all the way back to the enormous differences of style and results from the ARPA community compared to the Bell Labs community), why is there any burden of proof here? For example, we published in 1983 a still readily available (including online) book (Smalltalk-80 and its implementation) about how Smalltalk is implemented and bootstrapped, and there is a readily available paper about the more recent Squeak version which was built on that. And there is ample information available at the Squeak site. Folks who are willing to understand actually put some effort into it instead of jumping to conclusions based on internal logic and scant information rather than available external evidence. We have seen many claims about many things -- for example, where the source code might or might not be -- but scant evidence that any effort was made to find out. As I mentioned previously, this seems more like stories than reality. And it seems like a culture clash, where one culture thinks it is somehow standard, and other ways are not. The use of an image goes back further than Unix and C text files (one of the earliest good versions of this was BBN Lisp, which became Interlisp, in the latter part of the 60s), so this is at least as standard as any other way to build things. At PARC, this idea went further, because Smalltalk served as the entire environment of the PARC computers, and there was no separate OS, file system, etc. If you think about it this way, then you can see that the Smalltalk image is simply the entire virtual environment for Smalltalk computing. So it is quite equivalent to the package of stuff in the Unix world that includes text files, OS, tools, etc. The sources and changes files (the changes are the incremental history to the sources) don't have to be external to the image, but they have been made so since Smalltalk started to be implemented on computers that had fallen back to the bad old idea of operating systems and file systems. This is easy to find out about in a variety of ways. But there is something further to ponder about this method from the 70s. And that is the idea that as scaling advances under Moore's Law, it will be less and less a good idea to rebuild from scratch (and more and more difficult). For example, the most comprehensive object oriented system on the planet is the Internet itself, with the hardware computers as the objects, and TCP/IP as the underlying messaging system. This was invented and built by the very same computer research community (ARPA/PARC) that invented and built Smalltalk, the personal computers, GUI and Ethernet, etc., at PARC. Part of the idea here was that computing is going to have to learn how to completely build and completely change all computer systems while they are running and without being able to take them down for maintenance. This was done successfully for the Internet and for Smalltalk. Another part of the idea is that if you have a really strong and better system, why not be able to use it to improve itself (why go back to decontextualized editors and simplistic systems builds, etc.)? In any case, all of this has been well documented and available for decades. I, for one, am happy to answer any questions put to us about how our system works (why it bootstraps so well and completely), but I have no interest in spending any time defending against opinions that are not well informed. Best wishes to all, Alan - Original Message From: Edward Cherlin [EMAIL PROTECTED] To: Yoshiki Ohshima [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; devel@lists.laptop.org Sent: Friday, June 27, 2008 6:44:26 PM Subject: Re: [IAEP] etoys now available in Debian's non-free repository I am no slouch at understanding a bootstrap process, but it has taken me a few days to find the information I'm trying to understand by myself, given the refusal to even consider that someone might need this information in order to answer Debian's concerns, and thus the refusal to provide the pointers to it. So it is no surprise to me that Debian still has those concerns. It is no good being right if you can't explain or demonstrate _why_ you are right in terms that make sense to someone else who is willing to understand, but doesn't know how. On Fri, Jun 27, 2008 at 11:17 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: At Thu, 26 Jun 2008 23:43:45 -0700, Edward Cherlin wrote: I think that the result of all this is that we can produce all of the C (or some other language, maybe CLOS) and Smalltalk source files that Debian wants (even if we think of the C as compiler output, we don't have to bother them with that interpretation.) One of the compilers translates a subset of Smalltalk to C, but I gather that other compilers can translate all of Smalltalk/Squeak/Etoys/what you like to their chosen target language. Now I see
Re: [IAEP] etoys now available in Debian's non-free repository
At Tue, 24 Jun 2008 17:12:23 -0400, Frank Ch. Eigler wrote: 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, BTW, have you now understood that this was not true? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Yoshiki Ohshima [EMAIL PROTECTED] writes: 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, BTW, do you now agree that this was not true? If you give me an image file and ask me why the word at offset 0x12345 in the file is 0x89ABCDEF?, I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object., etc. Yes, that sounds much better (from a security/trust point of view) than having to ask the virtual machine itself to introspect. It stills seems somewhat too low level to enable version control. (Back in the early 90's, when I wrote Smalltalk code for a living (sort of), we ended up having to use external system (teamwork/envy IIRC) to get decent version control and reproducible builds.) It may be a useful exercise to run this over the whole etoys image to identify those parts that are recompilable from the .source/.changes files, those that represent plain data that could be serialized, and perchance surprise objects whose existence was only known to Alan Kay or Adele Goldberg back in the 80s. :-) - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
After writing the most of reply here, I found it now largely off-topic (thanks to Frank for understanding!) At Wed, 25 Jun 2008 21:00:24 -0400, Frank Ch. Eigler wrote: Yoshiki Ohshima [EMAIL PROTECTED] writes: 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, BTW, do you now agree that this was not true? If you give me an image file and ask me why the word at offset 0x12345 in the file is 0x89ABCDEF?, I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object., etc. Yes, that sounds much better (from a security/trust point of view) than having to ask the virtual machine itself to introspect. Well, if you understand more about the relationship between InterpreterSimulator and the VM, external or not would not make so much difference. And, the VM is compiled by a foreign system (a C compiler), there cannot be a place to hide something like Tompson's attack. External or not wouldn't be the factor. (And you probably meant that better than asking the image itself.) It stills seems somewhat too low level to enable version control. (Back in the early 90's, when I wrote Smalltalk code for a living (sort of), we ended up having to use external system (teamwork/envy IIRC) to get decent version control and reproducible builds.) Of course, what you would like to version control is the code people write. ENVY and others are designed for that purpose. For doing version control, we could more or less freeze an image to be a base (like our etoys-dev-3.0.image), and make a release image automatically by applying the updates (http://tinlizzie.org/updates/etoys/updates/) and evaluate the do it (ReleaseBuilderSqueakland new prepareReleaseImageForOLPC) from a Makefile (if that makes people happy). The diffs are all in small textual files. As long as you trust the base image, you only have to look at the updates. Now and then, we may want to change the base image. We do something that gave the perception to people that the previous base image is trustable there and that would do. It may be a useful exercise to run this over the whole etoys image to identify those parts that are recompilable from the .source/.changes files, those that represent plain data that could be serialized, and perchance surprise objects whose existence was only known to Alan Kay or Adele Goldberg back in the 80s. :-) I don't know in what sense it is *useful*, but the core image of Spoon (http://netjam.org/projects/spoon/) is 1,337 bytes (and of course every byte is understood). -- Yoshiki (And '80s is wrong time to go back in that sense, and Alan Kay and Adele Goldberg aren't the names to be mentioned in that context.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
John and others seem to be making the argument that unless something is technologically similar to GCC (in the way it is distributed, developed, and coded) it can't be --- picking a term --- open source. For example, Albert says that code has to be manageable by traditional SCM tools, patch tools, diff tools, editing tools, etc to be called source code. Different tools need not apply. It seems to me to be a little narrow to define software freedom in terms of specific (traditional) development tools; in the same way that it seems narrow to define a vehicle as something powered by an animal that eats oats. Isn't it enough for free software to be software that is free (both as in beer and speech)? Or does it also have to be editable by Emacs? -- Robert Withrow, R.W. Withrow Associates, Swampscott, MA, USA ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Robert Withrow [EMAIL PROTECTED] writes: John and others seem to be making the argument Only seem. that unless something is technologically similar to GCC (in the way it is distributed, developed, and coded) it can't be --- picking a term --- open source. [...] Not at all. 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, and cannot even be rebuilt from the sources it claims to contain. Someone else threw out the Thompson compiler hack and GCC as if it were an answer to this concern. Instead, it turns out that GCC is on the other (positive) extreme of bootstrappability. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
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. and cannot even be rebuilt from the sources it claims to contain. even be rebuilt from the sources ... why would you want to do that? It could be done, as well as you could tear down the Empire State building and rebuild it from scratch, but why? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
On Wed, 25 Jun 2008, 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. and cannot even be rebuilt from the sources it claims to contain. even be rebuilt from the sources ... why would you want to do that? It could be done, as well as you could tear down the Empire State building and rebuild it from scratch, but why? leaving aside all the opensource arguments and just looking at it from a purely pragmatic point of view: becouse paranoid people want to be able to verify that what's in the blob is really what it claims to be. and we need to support these paranoid people becouse there are people who really are out to get us, and the small number of paranoid people protect us all. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Am 25.06.2008 um 00:12 schrieb [EMAIL PROTECTED]: On Wed, 25 Jun 2008, 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. and cannot even be rebuilt from the sources it claims to contain. even be rebuilt from the sources ... why would you want to do that? It could be done, as well as you could tear down the Empire State building and rebuild it from scratch, but why? leaving aside all the opensource arguments and just looking at it from a purely pragmatic point of view: becouse paranoid people want to be able to verify that what's in the blob is really what it claims to be. That would be accomplished by the tool I mentioned above. and we need to support these paranoid people becouse there are people who really are out to get us, and the small number of paranoid people protect us all. I think you forgot a smiley to mark this as sarcasm. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
On Tue, 2008-06-24 at 11:41 -0700, John Gilmore wrote: Jim: My point is somewhat different: the only way out of the compilation trust trap is another compiler. Unless someone has done this for gcc, it has the identical problem, and there are many possible upstream attacks. I see no reason (probably less) to trust the chain of trust for gcc than I do Squeak, as the rewards of attacking gcc are so much higher. Alan: We are dealing with stories here, not with any kind of reality. Here's a story for you. GCC is regularly compiled with non-GCC compilers. It has been bootstrapped thousands of times, using dozens of different compilers (Sun's, Intel's, Apple's MPW, Green Hills, Code Warrior, MIPS's, ...). GCC includes lots of hacks and configuration code to allow it to build on other vendors' buggy or divergent compilers. I've bootstrapped it myself hundreds of times, and Cygnus built the testing infrastructure to do it nightly on many architectures. The makefiles are set up to do the classic 3-stage bootstrap: stage1 = binaries from GCC sources compiled with vendor compiler stage2 = binaries from GCC sources compiled with stage1 GCC stage3 = binaries from GCC sources compiled with stage2 GCC We then make sure that the stage2 and stage3 binaries are identical. (This check has caught hundreds of bugs in gcc, binutils, and in vendor compilers.) Ah, yes, I remember this. I've even struggled to do this once or twice, but that was about 15 years ago... (The 3-stage bootstrap does not prevent or detect a Ken Thompson style all-binary attack -- but to succeed on a particular platform, you'd have to patch both the vendor compiler and GCC, and keep these patches in sync over time. GCC also supports full blown cross-compilation (of itself and anything else), so a cross-bootstrap from any other host architecture would break the chain of an all-binary attack. Debian's issue is not about resistance to Thompson attacks; this is just an aside.) It is trivial to build working binaries of GCC from a source tree, if you have a C compiler from any other source. ./configure make install. This is quite different from the eToys situation, in which there is a single binary implementation of the language; and the sources, where present, are all mixed into a binary blob that's only readable by the single implementation. I have the same concerns that Debian does. Is there even a tool internal to eToys that confirms that everything in a blob includes the matching source? Let alone a tool that would extract that source and rebuild the blob from scratch, using a virgin binary environment. We could've bootstrapped GCC once, and limped along ever afterward with binaries built from that one original GCC binary. (In a sense, the entire C compiler market has done this. Bell Labs' original C compiler was bootstrapped from a BCPL compiler, and every other C compiler probably bootstrapped from Bell's C compilers.) Instead, the GCC maintainers built lots of infrastructure to allow GCC to be bootstrapped anytime somebody wants to. And to test it regularly. That's the part that eToys hasn't done. It turns out to be quite hard to reproduce a GCC release or Linux release, bit-for-bit identical, from its source tree. If you haven't tested it, I'd pretty much guarantee that it isn't working. It has subtle dependencies on its build environment, which predates the release. GCC depends on the binutils, on libc, and on many external include files, for example. Even unpacking a source release depends on tar and gzip or bzip2, each of which depends on the installed shared libc. Cygnus was bit by such build-environment dependencies several times, when trying to produce patches against its old GCC binary releases. Are Fedora releases verified before release to build an identical binary CD/DVD image, starting from only a bare Fedora (release X) bootable binary CD/DVD, a freshly bought bare PC, and the pile of source code RPMs in the Fedora (release X) source CD/DVD? (I think not -- I don't see source or binaries of pilgrim, which makes the bootable CD image.) Are Debian releases tested to reproduce themselves the same way? Perhaps eToys can get a reprieve until Debian confirms that it, itself, can do what it asks of eToys. John PS: Several distros don't make it easy to *find* source code releases. There's no obvious path on http://getfedora.com to get the definitive F9 source code release; you have to troll around in the mirrors looking for it. OLPC will groan when it gets the first letter asking for the matching sources for its binary (flash) release. It's only a few cranky geeks like me who insist on actually obtaining the sources for their free binary software. I hope/believe Dennis has this cleaned up now I'll check to make sure. Please pick on Fedora first, as they are upstream of us ;-). Back to the
Re: [IAEP] etoys now available in Debian's non-free repository
My point is somewhat different: the only way out of the compilation trust trap is another compiler. Unless someone has done this for gcc, it has the identical problem, and there are many possible upstream attacks. I see no reason (probably less) to trust the chain of trust for gcc than I do Squeak, as the rewards of attacking gcc are so much higher. So to what standards should one hold squeak vs. gcc? - Jim On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote: Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400 On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote: Plus it requires them (and users) to run the tools embedded into the possibly suspect image in order to describe itself. Do you see how there could be a trust problem there? Note this is no different than any time you use a compiler binary provided by someone else... The attack is just as complete... http://cm.bell-labs.com/who/ken/trust.html If that's the best attempt to reassure etoys users/packagers, no wonder the debian people are balking. The Thompson Trojan is a noteworthy idea, but surely you see the wholly different degree of paranoia we're talking about when we're asked to trust a decades-old virtual machine image as compared to a bootstrappable system. I think Jim's point is valid - you have to consider very carefully every link in your web of trust and understand just how complex it is if you want a realistic notion of security. And you have to be clear about your needs. As an extreme example: most x86 processors currently have enough spare transistors to easily hide an attack similar to the one described in the cited paper. I don't think anybody here would spend even a single second worrying about Intel or AMD, right? But a person in a country that might go to war with the USA might have to think about it. Squeak, and Smalltalk in general, represents the opposite extreme in that it was mostly developed in that 1970s hacker spirit that gave us SMTP and other equally secure systems. And here we run into a common problem in the Squeak community: there are those who can (easily, even) do something and there are those who feel it is a top priority to do that something, but hardly ever there is an overlap between the two groups. In the case of security most of the development effort is happening in the form of forks rather than changes to Squeak itself, so that doesn't help the problem we are discussing at all. One way to deal with weak links in a web of trust is to have more parallel links. If you have several tools with separate origins then an attack that depends on their cooperation will be very unlikely. A tool in Python that could investigate a Squeak image file, as has been suggested, would be an example of using parallel links. About the issue of sourceless objects, this is something that varies from image to image. If you start out from some standard image and use the paint tool to make a few drawings and open new workspaces and type some notes into them then your new image will be more problematic than the original. It is likely that with some effort you could have a usable image that contained absolutely no objects like this at all. Some other Smalltalks have this, which shows it isn't a technical problem. So we have two things that should be done: a tool in a language other than Smalltalk that can inspect Squeak images and an image which can be generated from the sources using that tool. Who will do it? I can't think of a name to suggest, which is the problem I mentioned above. -- Jecel ___ Its.an.education.project mailing list [EMAIL PROTECTED] http://lists.lo-res.org/mailman/listinfo/its.an.education.project -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
Exactly! Jim sees the real problem. We are dealing with stories here, not with any kind of reality. Cheers, Alan - Original Message From: Jim Gettys [EMAIL PROTECTED] To: Jecel Assumpcao Jr [EMAIL PROTECTED] Cc: its. an. education. project [EMAIL PROTECTED]; OLPC Devel devel@lists.laptop.org Sent: Monday, June 23, 2008 12:00:10 PM Subject: Re: [IAEP] etoys now available in Debian's non-free repository My point is somewhat different: the only way out of the compilation trust trap is another compiler. Unless someone has done this for gcc, it has the identical problem, and there are many possible upstream attacks. I see no reason (probably less) to trust the chain of trust for gcc than I do Squeak, as the rewards of attacking gcc are so much higher. So to what standards should one hold squeak vs. gcc? - Jim On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote: Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400 On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote: Plus it requires them (and users) to run the tools embedded into the possibly suspect image in order to describe itself. Do you see how there could be a trust problem there? Note this is no different than any time you use a compiler binary provided by someone else... The attack is just as complete... http://cm.bell-labs.com/who/ken/trust.html If that's the best attempt to reassure etoys users/packagers, no wonder the debian people are balking. The Thompson Trojan is a noteworthy idea, but surely you see the wholly different degree of paranoia we're talking about when we're asked to trust a decades-old virtual machine image as compared to a bootstrappable system. I think Jim's point is valid - you have to consider very carefully every link in your web of trust and understand just how complex it is if you want a realistic notion of security. And you have to be clear about your needs. As an extreme example: most x86 processors currently have enough spare transistors to easily hide an attack similar to the one described in the cited paper. I don't think anybody here would spend even a single second worrying about Intel or AMD, right? But a person in a country that might go to war with the USA might have to think about it. Squeak, and Smalltalk in general, represents the opposite extreme in that it was mostly developed in that 1970s hacker spirit that gave us SMTP and other equally secure systems. And here we run into a common problem in the Squeak community: there are those who can (easily, even) do something and there are those who feel it is a top priority to do that something, but hardly ever there is an overlap between the two groups. In the case of security most of the development effort is happening in the form of forks rather than changes to Squeak itself, so that doesn't help the problem we are discussing at all. One way to deal with weak links in a web of trust is to have more parallel links. If you have several tools with separate origins then an attack that depends on their cooperation will be very unlikely. A tool in Python that could investigate a Squeak image file, as has been suggested, would be an example of using parallel links. About the issue of sourceless objects, this is something that varies from image to image. If you start out from some standard image and use the paint tool to make a few drawings and open new workspaces and type some notes into them then your new image will be more problematic than the original. It is likely that with some effort you could have a usable image that contained absolutely no objects like this at all. Some other Smalltalks have this, which shows it isn't a technical problem. So we have two things that should be done: a tool in a language other than Smalltalk that can inspect Squeak images and an image which can be generated from the sources using that tool. Who will do it? I can't think of a name to suggest, which is the problem I mentioned above. -- Jecel ___ Its.an.education.project mailing list [EMAIL PROTECTED] http://lists.lo-res.org/mailman/listinfo/its.an.education.project -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Its.an.education.project mailing list [EMAIL PROTECTED] http://lists.lo-res.org/mailman/listinfo/its.an.education.project ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
