Mark Miller | 1 Feb 03:43 2009
Picon

Re: Jacaranda draft specification

2008/8/22 David-Sarah Hopwood <david.hopwood-mRVxzIiVagSlV3Ge8JjJtnfLna9zW77M@public.gmane.orguk>
[...]

Sorry for the bizarreness of having a message from August last year suddenly show up. It's delay was a moderation oversight on my part. (It was held for moderation because of its size.)

--
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Mark Miller | 4 Feb 22:21 2009
Picon

Java security hole in interplay of stack introspection & deserialization

http://slightlyrandombrokenthoughts.blogspot.com/2008/12/calendar-bug.html

--
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Tyler Close | 5 Feb 02:35 2009
Picon

Bang Tutorial redux -- javascript promises

Hi all,

I've been knee deep in Waterken server code for a few months now,
making some changes to make it perform better and be easier to review.
Anyways, I've finally gotten back to the stage where the next version
is in a usable state, and so I've been working on the new Javascript
interface. This version follows the ADsafe conventions and uses a
different syntax. There's a test page / tutorial at:

https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p

I'm looking for some testing and criticism of the Javascript API.

Bill Frantz has been talking about using this interface as a remote
shell for CapROS <http://www.capros.org/>. If so, this same API should
work cross-platform across the Waterken Server and CapROS.

Thanks,
--Tyler
Toby Murray | 5 Feb 11:11 2009
Picon
Picon

Re: Bang Tutorial redux -- javascript promises

On Wed, 2009-02-04 at 17:35 -0800, Tyler Close wrote:
> Hi all,
> 
> I've been knee deep in Waterken server code for a few months now,
> making some changes to make it perform better and be easier to review.
> Anyways, I've finally gotten back to the stage where the next version
> is in a usable state, and so I've been working on the new Javascript
> interface. This version follows the ADsafe conventions and uses a
> different syntax. There's a test page / tutorial at:
> 
> https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p
> 
> I'm looking for some testing and criticism of the Javascript API.
> 

Looking at it quickly, I think I prefer the old syntax. How come the
change? What advantages does the new syntax have?

Why the name Q?

Cheers

Toby
Tyler Close | 5 Feb 15:38 2009
Picon

Re: Bang Tutorial redux -- javascript promises

On Thu, Feb 5, 2009 at 2:11 AM, Toby Murray <toby.murray@...> wrote:
> On Wed, 2009-02-04 at 17:35 -0800, Tyler Close wrote:
>> Hi all,
>>
>> I've been knee deep in Waterken server code for a few months now,
>> making some changes to make it perform better and be easier to review.
>> Anyways, I've finally gotten back to the stage where the next version
>> is in a usable state, and so I've been working on the new Javascript
>> interface. This version follows the ADsafe conventions and uses a
>> different syntax. There's a test page / tutorial at:
>>
>> https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p
>>
>> I'm looking for some testing and criticism of the Javascript API.
>>
>
> Looking at it quickly, I think I prefer the old syntax. How come the
> change? What advantages does the new syntax have?

The _ convention in the previous syntax was not compatible with the
Google coding conventions, which use a trailing _ to denote a private
member field in an object.

With the previous syntax, there was also a danger that a programmer
would try to do an eventual operation without checking that the target
object was actually a promise (by passing it through the _()
function). In the current syntax, there's no way to write an eventual
operation that is not safe: all eventual operations are invocations on
the Q object.

ADsafe doesn't support freezing of an object, so separate clients of
the same promise could tamper with that promise's API, such as by
replacing the value of the promise's "post" member. With the current
API, it's not possible for ADsafe code to tamper with the behaviour of
a promise.

> Why the name Q?

Best we could come up with. Think of it as meaning: "This operation is
queued for later, not done now."

--Tyler
Toby Murray | 5 Feb 19:09 2009
Picon
Picon

Re: Bang Tutorial redux -- javascript promises

On Thu, 2009-02-05 at 06:38 -0800, Tyler Close wrote:
> On Thu, Feb 5, 2009 at 2:11 AM, Toby Murray <toby.murray@...> wrote:
> > On Wed, 2009-02-04 at 17:35 -0800, Tyler Close wrote:
> >> Hi all,
> >>
> >> I've been knee deep in Waterken server code for a few months now,
> >> making some changes to make it perform better and be easier to review.
> >> Anyways, I've finally gotten back to the stage where the next version
> >> is in a usable state, and so I've been working on the new Javascript
> >> interface. This version follows the ADsafe conventions and uses a
> >> different syntax. There's a test page / tutorial at:
> >>
> >> https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p
> >>
> >> I'm looking for some testing and criticism of the Javascript API.
> >>
> >
> > Looking at it quickly, I think I prefer the old syntax. How come the
> > change? What advantages does the new syntax have?
> 
> The _ convention in the previous syntax was not compatible with the
> Google coding conventions, which use a trailing _ to denote a private
> member field in an object.

Right. Fair enough.

> With the previous syntax, there was also a danger that a programmer
> would try to do an eventual operation without checking that the target
> object was actually a promise (by passing it through the _()
> function). In the current syntax, there's no way to write an eventual
> operation that is not safe: all eventual operations are invocations on
> the Q object.

I see.

> ADsafe doesn't support freezing of an object, so separate clients of
> the same promise could tamper with that promise's API, such as by
> replacing the value of the promise's "post" member. With the current
> API, it's not possible for ADsafe code to tamper with the behaviour of
> a promise.

Indeed. The lack of freezing-support is actually quite a nuisance
generally here.

> > Why the name Q?
> 
> Best we could come up with. Think of it as meaning: "This operation is
> queued for later, not done now."

Does the ref_send API expose functionality through any other interface
besides the global Q object? If not, a name that denotes the library
might be less confusing. Q is also fairly low-entropy, increasing the
chance of a collision of global variable names, although this risk is
pretty small.

That said, I'm not sure there's a better alternative.

Thanks for the explanations. I understand the need for the changes now.

Cheers

Toby
Kevin Reid | 7 Feb 02:03 2009
Picon

Quick note on missing series features

I tried to use elang.control.makeSeries in a demonstration program. I  
found it lacking:

1. There is asList and asMap, but no asSet.

2. There is no facility to produce a series with specified keys. That  
is, it is impossible to do this using series:

   accum [].asMap() for [k, v] in foo { _.with(f(k), f(v)) }

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Kevin Reid | 7 Feb 02:18 2009
Picon

Missing features in pattern failure

   accum [].asMap() for [k, v] in foo { _.with(k, v) }

This code does not do the right thing if one of the elements of foo is  
not a pair: it will skip it rather than failing. Currently this has to  
be rewritten using an explicit def:

   accum [].asMap() for temp ? (def [k, v] := temp; true) in foo  
{ _.with(f(k), f(v)) }

or

   accum [].asMap() for temp in foo { _.with(def [k, v] := temp; f(k),  
f(v)) }

but both of these are ugly.

What I would like for this is something like Haskell's "irrefutable  
patterns", which turn match failure in a subpattern into a program  
failure.

This comes to mind:

   accum [].asMap() for via (irrefutable) [k, v] in foo { _.with(f(k),  
f(v)) }

but with the current protocol for a via-function, it can't control  
what ejector is supplied to a subpattern.

This inability has another effect:
----------------------------------------------------------------------

Since nothing in in a Kernel-E pattern does or can substitute the  
ejector, once a match of some pattern against some value has failed,  
it is impossible to reconstruct which part of the value did not match.  
If the ejectors for subpatterns were nested (much as happens in the  
interaction between TextWriters and printed objects) then we could  
construct a chain of nested exceptions as we unwind in the pattern  
which documents where the failure was.

Example:

   def [==1, [==2, [==3, ==4]]] := [1, [2, [9, 4]]]

would generate the exception

   makeTupleFailure(1,
     makeTupleFailure(1,
       makeTupleFailure(0,
         makeSamePattFailure(9, 3)))

When each ListPattern executes its subpatterns, it provides an ejector  
which calls the outer ejector:

   to matchBind(specimen, ejector, env) {
     for index => subpattern in myPatterns {
       subpattern.matchBind(specimen, fn subfailure {
         ejector(makeTupleFailure(index, subfailure))
       }, env)
     }
   }

Similarly, ViaPattern would need to be changed such that the via- 
function can specify the ejector the subpattern gets, as well as the  
specimen.

(ListPattern and ViaPattern are the only non-atomic patterns remaining  
in Kernel-E.)

I think this might enable some interesting uses, but I don't have any  
concrete examples besides "nice error messages". They would be very  
nice error messages, though.

On the other hand, it's a lot of objects to be allocated. But a lot of  
uses of 'via' generate closures each time anyway; perhaps the answer  
is "just" work on optimizing them out (don't make reified nested  
ejectors if you can compile the patterns; don't make exceptions if  
nothing is looking).

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
David Wagner | 9 Feb 04:25 2009
Picon

Re: Java security hole in interplay of stack introspection & deserialization

Mark Miller  wrote:
> http://slightlyrandombrokenthoughts.blogspot.com/2008/12/calendar-bug.html

Thanks for pointing us to this.

Obligatory Joe-E tie-in: I'm trying to figure out whether Joe-E was
ever vulnerable to this attack.  It looks like the particular attack
method described in the blog post would not work on Joe-E.  The attack
described on the blog involves both a custom readObject code in the
attack object and storing a reference into a static field.  Of course
Joe-E bans mutable static fields, but more importantly, As part of Joe-E's
"attack surface reduction", we ban serialization (including prohibiting
Joe-E code from implementing readObject or writeObject).  So as far as
I can see, it looks like Joe-E code could not implement the particular
attack described in that blog post.

Does anyone see whether there is any other way that Joe-E code could
have exploited this vulnerability in stack inspection?  Would it be
accurate to say that Joe-E's banning of features incompatible with
capability programming happened to defend against this vulnerability,
even though we didn't know of this vulnerability at the time we designed
Joe-E?
David Wagner | 9 Feb 04:32 2009
Picon

Joe-E command-line verifier

I don't think anyone ever announced this, so I thought I might as well
make note of it, for those who may be interested:

Earlier this year Adrian quietly released a version of Joe-E that includes
a command-line verifier, so that the Joe-E verifier can be used from the
command line in batch mode (without requiring use of the Eclipse GUI).
This was implemented by a Berkeley students Akshay Krishnamurthy and Kanav
Arora, under Adrian Mettler's direction and with Adrian's assistance.
Thanks, Akshay, Kanav, and Adrian!

Gmane