Squeak-e

squeak-e@lists.squeakfoundation.org

54 discussions

List Closure
by Bruce O'Neel 22 Jul '23

22 Jul '23

Hello all, This mailing list has been inactive for a long time and as a result it will be closed. Any discussions that you would have had here are very welcome on squeak-dev in order to increase the dynamism of the Squeak community. We of course will keep the archives. Thanks Bruce as a representative of the Squeak Board.

1 0

(no subject)
by Jorge Staloe 22 Oct '20

22 Oct '20

1 0

[Fwd: [e-lang] A dissertation on the rationale, philosophy, and goals of E and related systems]
by Mark S. Miller 16 Apr '06

16 Apr '06

-------- Original Message -------- Subject: [e-lang] A dissertation on the rationale, philosophy, and goals of E and related systems Date: Sat, 15 Apr 2006 20:06:30 -0700 From: Mark S. Miller <markm(a)cs.jhu.edu> Reply-To: Discussion of E and other capability languages <e-lang(a)mail.eros-os.org> To: Discussion of E and other capability languages <e-lang(a)mail.eros-os.org>, "General discussions concerning capability systems." <cap-talk(a)mail.eros-os.org>, oz-e(a)info.ucl.ac.be, Mozart <users(a)mozart-oz.org>, Squeak-E <squeak-e(a)lists.squeakfoundation.org>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>, p2p-hackers(a)zgp.org, anti-fraud(a)lists.cacert.org, croquet(a)lists.wisc.edu, modules(a)discuss.squeakfoundation.org, hcisec(a)yahoogroups.com Apologies for the wide distribution, but elements of this dissertation are germane to each of these lists. Feedback appreciated, but please reply to me or on an appropriate list, rather than using "Reply all". The copyright notice is interim, until I figure out what open license I want on this. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain. My dissertation at Johns Hopkins University, found at http://www.erights.org/talks/thesis/index.html Advisor: Jonathan S. Shapiro. Readers: Scott Smith, Yair Amir. -- Cheers, --MarkM

1 0

Status
by Mariano Montone 12 Feb '06

12 Feb '06

Hello I want to know what's the state of Squeak-E. I have already seen the wiki and there's some code, but I have to recompile the vm. Does anyone have or knows how to get a precompiled Squeak-E VM + Image (I'm working on Windows right now). Besides, the mailing list seems to be silent. What happend to the project? Thanks, Mariano

1 0

(no subject)
by aimee.hilliard2＠mail.dcu.ie 13 Apr '05

13 Apr '05

Hi All, I am trying to build a game using squeak for a college project. I am finding squeak very difficult I cannot seem to make a start. The game will be targeted towards young children and it is supposed to help them learn Irish. So as one part of the game I have decided to do a simple crosword where the clue is an english word and the answer is the irish meaning(word) for that word. I have started by creating a subclass of CrosticPanel. i am now pretty much stuck. Any help would be great and very appreciated! Thanks Aimee

2 2

Modules etcetera on squeak-dev
by Cees de Groot 26 Feb '05

26 Feb '05

Hi, I'm not sure how many subscribe here that do not subscribe or actively follow squeak-dev, but a team is forming to work towards a short-term 'modules' thingy for Squeak. Dan Ingalls leads the team, and he wants to implement The Simplest Thing With The Largest Impact - which means that he is looking at stuff like E, Vats so that modules could have security implications (implications in the positive sense). Anyway, there's a mailing list (modules-subscribe(a)discuss.squeakfoundation.org) and a Swiki page to discuss this all (http://minnow.cc.gatech.edu/squeak/5608) so if you think you've got something to add from the E perspective, this is probably The Chance. Regards, Cees

2 3

New paper: The Structure of Authority
by Mark Miller 12 Nov '04

12 Nov '04

At <http://www.erights.org/talks/no-sep/index.html>. [Caution: wide distribution. Please send replies only to a narrower addressee list. Thanks.] The Structure of Authority: Why security is not a separable concern by Mark S. Miller, Bill Tulloh, and Jonathan Shapiro Common programming practice grants excess authority for the sake of functionality; programming principles require least authority for the sake of security. If we practice our principles, we could have both security and functionality. Treating security as a separate concern has not succeeded in bridging the gap between principle and practice, because it operates without knowledge of what constitutes least authority. Only when requests are made -- whether by humans acting through a user interface, or by one object invoking another -- can we determine how much authority is adequate. Without this knowledge, we must provide programs with enough authority to do anything they *might* be requested to do. We examine the practice of least authority at four major layers of abstraction -- from humans in an organization down to individual objects within a programming language. We explain the special role of object-capability languages -- such as E or the proposed Oz-E -- in supporting practical least authority. -- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Re: [e-lang] Re: Croquet, Unum questions
by Mark Miller 23 Aug '04

23 Aug '04

On 2004, Jul 24, , at 19:05, Mark Miller wrote: >[...] Several of us were distracted, in a major way, this >week. More about that soon... We were distracted by an invitation-only workshop, held at HP Labs, focused on exploring future possibilities for Croquet. http://chess.eecs.berkeley.edu/croquet/ is a start on a website resulting from this workshop. The workshop was organized by Rick McGeer and attended by about 30 people, including * three of the main Croquet architects (David Smith, David Reed, and Andreas Raab), * several other Croquet-ers (Mark McCahill, Julian Lombardi) * and Squeakers (Dan Ingalls, Ted Keahler, Lex Spoon, Anthony Hannan, Ian Piumarta, Scott Wallace), * several members of the e-lang community (Chip Morningstar, Kevin Reid, Ka-Ping Yee, Marc Stiegler, Alan Karp, Tyler Close, Dean Tribble, and myself), * George Bosworth of Digitalk Smalltalk and .NET CLR fame, * Robert Adams of Intel and PlanetLab, * and Prof. Edward Lee of Berkeley. * (and probably some others I forgot) The Electric Communities and e-lang perspectives were represented well, and played well with other perspectives that were presented. I think the lessons from our perspectives were taken to heart, and their relevance to the Croquet undertaking were clear. Actually, I think I'm way understating the case, but I'll wait to see what others have to say. In any case, I think it's fair to say that we have consensus on using object-capability security as the underlying security mechanism, on top of which Croquet's security architecture should be built. And that we have consensus that "Threads are evil" -- that the conventional (shared memory multithreading & fine-grained locking) paradigm of concurrency is unworkable, and that instead, time should proceed according to a partial causal order among events, where each event is the deterministic execution of a sequential program to completion. (E and Croquet already have this perspective in common, but with some interesting differences.) I have asked the Croquet architects to evaluate the suitability of the Kernel-E virtual machine definition as a proposed foundation on which Croquet should be reconstructed. They are currently evaluating it. If adopted, the plan would probably be to start by completing Dean's E-on-Squeak effort in the short term, and do a more direct implementation of Kernel-E on their virtual machine infrastructure in the long term. At 04:05 PM 7/28/2004 Wednesday, Kevin Reid wrote: >>(Note: the picture painted here doesn't yet cover the case where there are >>potentially multiple authoritative presences. I now think I like Dean's >>proposal for that better than Uni-Tea >>http://www.erights.org/talks/uni-tea/index.html . > >I don't recall or never heard what Dean's proposal was. In the Uni-Tea proposal, we map a Tea Party to an Unum, and make the replication of authoritative presences be a generalization of presence spread among vats. Dean suggests that, instead, we map a Tea Party to a virtual vat, and implement fault tolerant replicated vats. Then, at the vat level of abstraction, an individual Unum would still just have one authoritative presence, permanently tied to its virtual vat of origin. Rather than making the replication, consensus, and fault tolerance protocols be Unum design choices, we should make these choices when instantiating a fault-tolerant replicated vat. In Dean's proposal, it is especially clear that you only do fault tolerant replication among sites mutually trusted to try to run their replicas correctly, since that vat's private key would be replicated at all those sites. -- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 1

Re: [cap-talk] automatic policy embodiment and enforcement
by Fred Spiessens 12 Aug '04

12 Aug '04

[Message by Fred, reposted to e-lang, users@mozart, and squeak-e by MarkM. I wanted to be sure y'all saw this. --MarkM] Toby, Three weeks ago Mark Miller, Jonathan Shapiro, Peter Van Roy and myself submitted a paper for POPL05, that is to be regarded as a first step in the direction you're pointing to. It does not yet deal with _automatic_ mapping of policy specifications towards relied-upon abstractions of behavior, but it contains a proposal for a formalism to express in which way relied-upon ("trusted") entities reduce their authority-providing behavior when interacting with other entities, and to consequently examine the resulting boundaries in authority propagation. We called it "Authority Reduction Systems" in the paper, and we derived its mechanisms and features from an analytical comparison between H.R.U. Protection Systems and Take-Grant Systems. I consider your remark as (one of) the next step(s) to be done now: 1) build tools that proof the "safety properties" of an arbitrary configuration that contains some entities of which (part of) their behavior restrictions are known or relied upon. 2) build tools that propose the injection of reliable entities at strategic places in a configuration, to assure a given set of "safety requirements" for a given class of configurations. I hope we will then also be able to translate arbitrary security paradigms into such "classes of initial configurations", with a minimal set of initial conditions, and reliable entities put at strategic places to enforce the policy. ( I'm not sure I make myself clear, I suggest you read the paper for more details) I've just started working towards such a tool, using techniques from constraint programming which are relatively new to me (all help is very welcome!). I think it is possible to build a tool that can find the minimum number of reliable entities to be injected, the minimum set of restrictions each of them should respect, and the best places amongst the other agents to install them, as to guarantee the requirements of an arbitrary security policy. You can find our paper "Authority Reduction in Protection Systems" on the MILOS project site: http://renoir.info.ucl.ac.be/twiki/bin/view/INGI/MILOSProject (last entry under the topic "Capability Theory") All comments on the paper are very welcome on this mailing list. I hope it will point you in the right direction. cheers, Fred. ------------------- Fred Spiessens UCL Louvain-la-Neuve Belgium http://www.info.ucl.ac.be/people/fsp/fred.html ------------- you're invited to: ------------------------- the Second International Mozart/Oz Conference (MOZ 2004) Charleroi, Belgium, Oct. 7-8, 2004 http://www.cetic.be/moz2004 ------------------------------------------------------------- On Aug 11, 2004, at 3:22 AM, Toby Murray wrote: >In my reading of literature regarding capability systems and implementations I'm yet to find any work that deals with the automatic mapping of an abstract policy specification (in whatever appropriate paradigm) to rules regarding capability propagation between entities, and trusted abstractions built over the base system. While it has recnetly been explicitly recognised in the literature (at least from my understanding) that trusted abstractions enforce security as well (and therefore are an embodiment of the policy) -- with the decisions regarding distribution of capabilities between entities being the other embodiment of policy -- it appears that we'll have to be able to build these abstractions and generate propagation rules automatically that can be enforced by trusted code, if capability systems are to become practical. >Perhaps capability systems make this problem harder because they allow almost arbitrary security paradigms (in which any policy must be framed) to be mapped onto the base system. (eg. we can do RBAC or Bell-LaPadula if we want to build the right abstractions and come up with the right rules etc.) We have seen very small examples here and there (eg. indirection for temporal revocation, and the example used by Shapiro et. al to show that the *-property can be enforced), but all of these must be crafted by a human who "knows" that the abstraction and associated rules actuall embody and enforce the abstract policy. >Has any work been done in this area and if so could someone point me in the right direction? > >Thanks, >Toby > >-- >Toby Murray >Software Engineer >Advanced Computer Capabilities Unit >Information Networks Division >DSTO, Australia > >IMPORTANT: This e-mail remains the property of the Australian Defence >Organisation and is subject to the jurisdiction of section 70 of the >Crimes Act 1914. If you have received this e-mail in error, you are >requested to contact the sender and delete the e-mail. > >_______________________________________________ >cap-talk mailing list >cap-talk(a)mail.eros-os.org >http://www.eros-os.org/mailman/listinfo/cap-talk _______________________________________________ cap-talk mailing list cap-talk(a)mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk

1 0

om?
by Alan Grimes 13 Mar '04

13 Mar '04

I don't remember reciving any trafick from this list.... I was reminded of the list by Brian Rice in IRC... When looking at this URL: http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000027.h… I was struck by the fact that this is ALMOST EXACTLY MY IDEA!!!! =P See paper at: http://users.rcn.com/alangrimes/UCE/sphere.txt Which is 2 years older.... SO WHERE THE HECK HAVE YOU PPL BEEN HIDING DURING THE 2 YEARS BETWEEN WHEN I PUBLISHED MY ARTICLE AND THIS E-MAIL POSTING? =P Anyway, lets get to work now... I reciently discovered Environment, what a brilliant class.... Prior to this discovery I wrote base and interface classes for my Sphere design... however I am extremely impressed by many of the design features of Environment. I was feebly trying to hack togeather a system that would allow me to visualize the graphical structure of the system........... =\ I later abandoned the graph concept for the sake of expediancy and have been futzing with the base security model, isolating the subtrees ( in the terminology of the e-mail reffered to above)... The only problem with this is that there are times when you WANT to violate the heirarchy of the system by putting a refferance to the root (or a peer) environment in some nested environment. This is necessary to support a "root shell" type thingy.... All these problems will be VERY whackable if everyone on this list will just spill what they know and start solving this stuff.

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e