<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Exactly! Jim sees the real problem.<br><br>We are dealing with stories here, not with any kind of reality. <br><br>Cheers,<br><br>Alan<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Jim Gettys <jg@laptop.org><br>To: Jecel Assumpcao Jr <jecel@merlintec.com><br>Cc: its. an. education. project <its.an.education.project@tema.lo-res.org>; OLPC Devel <devel@lists.laptop.org><br>Sent: Monday, June 23, 2008 12:00:10 PM<br>Subject: Re: [IAEP] etoys now available in Debian's non-free repository<br><br>
My point is somewhat different: the only way out of the compilation<br>trust trap is another compiler. Unless someone has done this for gcc,<br>it has the identical problem, and there are many possible upstream<br>attacks. I see no reason (probably less) to trust the chain of trust<br>for gcc than I do Squeak, as the rewards of attacking gcc are so much<br>higher.<br><br>So to what standards should one hold squeak vs. gcc?<br> - Jim<br><br><br>On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote:<br>> Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400<br>> > On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote:<br>> > > > Plus it requires them (and users) to run the tools embedded into the<br>> > > > possibly suspect image in order to describe itself. Do you see how<br>> >
> > there could be a trust problem there?<br>> > > <br>> > > Note this is no different than any time you use a compiler binary<br>> > > provided by someone else... The attack is just as complete...<br>> > > <a href="http://cm.bell-labs.com/who/ken/trust.html" target="_blank">http://cm.bell-labs.com/who/ken/trust.html</a><br>> > <br>> > If that's the best attempt to reassure etoys users/packagers, no<br>> > wonder the debian people are balking. The Thompson Trojan is a<br>> > noteworthy idea, but surely you see the wholly different degree of<br>> > paranoia we're talking about when we're asked to trust a decades-old<br>> > virtual machine image as compared to a bootstrappable system.<br>> <br>> I think Jim's point is valid - you have to consider very carefully every<br>> link in your "web of trust" and understand just how complex it is if you<br>> want a
realistic notion of security. And you have to be clear about your<br>> needs. As an extreme example: most x86 processors currently have enough<br>> spare transistors to easily hide an attack similar to the one described<br>> in the cited paper. I don't think anybody here would spend even a single<br>> second worrying about Intel or AMD, right? But a person in a country<br>> that might go to war with the USA might have to think about it.<br>> <br>> Squeak, and Smalltalk in general, represents the opposite extreme in<br>> that it was mostly developed in that 1970s hacker spirit that gave us<br>> SMTP and other equally secure systems. And here we run into a common<br>> problem in the Squeak community: there are those who can (easily, even)<br>> do something and there are those who feel it is a top priority to do<br>> that something, but hardly ever there is an overlap between the two<br>> groups. In the case of
security most of the development effort is<br>> happening in the form of forks rather than changes to Squeak itself, so<br>> that doesn't help the problem we are discussing at all.<br>> <br>> One way to deal with weak links in a web of trust is to have more<br>> parallel links. If you have several tools with separate origins then an<br>> attack that depends on their cooperation will be very unlikely. A tool<br>> in Python that could investigate a Squeak image file, as has been<br>> suggested, would be an example of using parallel links.<br>> <br>> About the issue of sourceless objects, this is something that varies<br>> from image to image. If you start out from some standard image and use<br>> the paint tool to make a few drawings and open new workspaces and type<br>> some notes into them then your new image will be more problematic than<br>> the original. It is likely that with some effort you could have a
usable<br>> image that contained absolutely no objects like this at all. Some other<br>> Smalltalks have this, which shows it isn't a technical problem.<br>> <br>> So we have two things that should be done: a tool in a language other<br>> than Smalltalk that can inspect Squeak images and an image which can be<br>> generated from the sources using that tool. Who will do it? I can't<br>> think of a name to suggest, which is the problem I mentioned above.<br>> <br>> -- Jecel<br>> _______________________________________________<br>> <a target="_blank" href="http://Its.an.education.pro">Its.an</a>.education.project mailing list<br>> <a ymailto="mailto:Its.an.education.project@lists.lo-res.org" href="mailto:Its.an.education.project@lists.lo-res.org">Its.an.education.project@lists.lo-res.org</a><br>> <a href="http://lists.lo-res.org/mailman/listinfo/its.an.education.project"
target="_blank">http://lists.lo-res.org/mailman/listinfo/its.an.education.project</a><br>-- <br>Jim Gettys <<a ymailto="mailto:jg@laptop.org" href="mailto:jg@laptop.org">jg@laptop.org</a>><br>One Laptop Per Child<br><br>_______________________________________________<br>Its.an.education.project mailing list<br><a ymailto="mailto:Its.an.education.project@lists.lo-res.org" href="mailto:Its.an.education.project@lists.lo-res.org">Its.an.education.project@lists.lo-res.org</a><br><a href="http://lists.lo-res.org/mailman/listinfo/its.an.education.project" target="_blank">http://lists.lo-res.org/mailman/listinfo/its.an.education.project</a><br></div></div></div><br>
</body></html>