headers
Kevin Reid | 4 Aug 2009 13:57
Picon
Gravatar

Re: (Caja-CapTP) Re: Mutual introduction & a species of whale

On Jul 8, 2009, at 20:15, Tyler Close wrote:
> On Mon, Jul 6, 2009 at 7:15 AM, Kevin Reid<kpreid@...> wrote:
>> On Jul 1, 2009, at 20:10, Tyler Close wrote:
>>
>>> On Wed, Jul 1, 2009 at 11:19 AM, Kevin Reid<kpreid@...> wrote:
>>>> I am currently not using Tyler's JS ref_send because its  
>>>> interface to
>>>> JavaScript appears to be incompatible with the sort CapTP wants  
>>>> (with
>>>> regard to object types and distinctions and so on).
>>>
>>> I'm surprised by that. Can you give me more details?
>>
>> The first thing I noticed (from the implementation of 'near') is that
>> any function is considered a promise. In a CapTP-style system, any
>> arbitrary unknown object should be treated as a Selfish object. I
>> could declare that 'functions are not objects', but that ...just
>> doesn't feel right, in this context.
>
> Anything else?
>
> I can put a marker on the promise functions if that's all you need.

I don't wish to take the time now to make a thorough study of whether  
they are compatible, especially as I already have an implementation of  
E-style refs; I will investigate the matter after I am no longer under  
the GSoC obligation to work on specific goals (August 17 --  
unfortunately).

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 9 Aug 2009 16:25
Picon
Gravatar

Re: Data-E: Removing fixed literal type set

On Jun 3, 2009, at 1:03, Kevin Reid wrote:

> The buildLiteral/1 message to Data-E builders is renamed buildAtom/1.
>
> A Data-E builder specifies the kinds of objects it will accept as
> atoms, by a guard which can be retrieved from it. (We need to choose
> the verb for this.)

I hereby choose the verb atomType/0.

Precedent: Collections' keyType/0 and valueType/0.

In Caja-CapTP, the result will be a predicate function rather than a  
guard, until such time as Cajita has an idiomatic guard facility  
(particularly, ejectors are currently missing).

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 2 comments |
headers
Mark S. Miller | 9 Aug 2009 19:54
Picon
Favicon

Re: Data-E: Removing fixed literal type set

On Sun, Aug 9, 2009 at 7:25 AM, Kevin Reid <kpreid-ee4meeAH724@public.gmane.org> wrote:

On Jun 3, 2009, at 1:03, Kevin Reid wrote:

> The buildLiteral/1 message to Data-E builders is renamed buildAtom/1.
>
> A Data-E builder specifies the kinds of objects it will accept as
> atoms, by a guard which can be retrieved from it. (We need to choose
> the verb for this.)

I hereby choose the verb atomType/0.

Precedent: Collections' keyType/0 and valueType/0.

Good.
 

In Caja-CapTP, the result will be a predicate function rather than a
guard, until such time as Cajita has an idiomatic guard facility
(particularly, ejectors are currently missing).

Draft guards and ejectors in T-cajita.js at <http://codereview.appspot.com/105065/show>.

 
--
   Cheers,
   --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 1 comment |
headers
Mark S. Miller | 9 Aug 2009 20:26
Picon
Favicon

Re: Data-E: Removing fixed literal type set

On Sun, Aug 9, 2009 at 10:54 AM, Mark S. Miller <erights-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:


In Caja-CapTP, the result will be a predicate function rather than a
guard, until such time as Cajita has an idiomatic guard facility
(particularly, ejectors are currently missing).

Draft guards and ejectors in T-cajita.js at <http://codereview.appspot.com/105065/show>.

Very similar of course to the pattern you compile to in the visitEscapeExpr() method of E-on-JavaScript's lib-host/org/erights/eojs/compiler.emaker

Given this helper function, could visitEscapeExpr() compile to more compact code by using it? Should it?

--
   Cheers,
   --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 0 comments |
headers
stay | 11 Aug 2009 19:16
Picon
Favicon

Re: [Capsicum-team] Re: Fwd: [Caja] Shakhar

OK, I changed it to Shahar.

On Tue, Aug 11, 2009 at 6:34 AM, Ihab Awad<ihab@...> wrote:
> Fwiw, I think Daniel is right:
>
> http://en.wikipedia.org/wiki/Shahar_%28god%29
>
> Ihab
>
> On Mon, Aug 3, 2009 at 3:31 AM, MC Get Vizzy <dglibicki@...> wrote:
>>
>> did you consider "Shahar"?  I believe that would be the standard
>> academic transliteration.  (it's the same letter as the first letter
>> of "Heftza".)  the more popular transliteration for Hebrew speakers
>> would probably be Shachar.
>>
>> and I was hoping that capabilities on AppEngine would be called
>> CapEngine.
>>
>> On Jul 28, 1:25 pm, "Mark S. Miller" <erights@...> wrote:
>> > ---------- Forwarded message ----------
>> > From: Mike Stay <metaweta@...>
>> > Date: Mon, Jul 27, 2009 at 2:23 PM
>> > Subject: [Caja] Shakhar
>> > To: Google Caja Discuss <google-caja-discuss@...>
>> >
>> > Ihab Awad and I have started a sub-project of Caja called "Shakhar".
>> > The name is Hebrew for the color of the sky just before dawn; it also
>> > puns on the SR-71 Blackbird and its replacement, the SR-91 Aurora,
>> > both of which are planes that "fly above the cloud".
>> >
>> > The idea is to run Javascript code both on the client and on an App
>> > Engine server to form una.  An unum will provide javascript code to
>> > instantiate a local presence in the browser; that code will be cajoled
>> > and endowed with authority by the user.  We'll use Kevin Reid's
>> > Caja-CapTP for the internal protocol.  An unum can also be serialized
>> > and persisted in the App Engine datastore.  We'll use web-keys for
>> > remote references.  We intend to implement a CapDesk-like environment
>> > for the UI.  Existing web apps can be tamed and exposed as una; one
>> > might provide the OpenSocial API as an unum.
>> >
>> > The hope is that by following this route, we can make a web platform
>> > that is entirely based on POLA and ocaps, allowing secure mash-ups of
>> > any web content, simply by sharing web-keys.
>> >
>> > All of the pieces have been implemented: Caja, App Engine, Rhino,
>> > Caja-CapTP, YUI, etc; it remains to wire them all together into
>> > something that can show others what a good web platform can do.
>> >
>> > There's plenty to do, and we encourage contributions.
>> >
>> > If you didn't understand one or more of the terms, here's a glossary
>> > on the project's site (currently the only content
>> > there):http://code.google.com/p/google-caja-shakhar/wiki/ShakharIntroduction
>> > --
>> > Mike Stay -
>> > metaweta@...://math.ucr.edu/~mikehttp://reperiendi.wordpress.com
>> >
>> > --
>> >     Cheers,
>> >     --MarkM
>
>

--

-- 
Mike Stay
stay@...
Permalink | Reply | 0 comments |
headers
stay | 12 Aug 2009 01:27
Picon
Favicon

Possible substrate for CapTP on https

http://blog.appenginefan.com/2009/07/faux-sockets-for-rich-java-clients.html

--

-- 
Mike Stay
stay@...
Permalink | Reply | 1 comment |
headers
David-Sarah Hopwood | 12 Aug 2009 03:11
Favicon
Gravatar

Re: Possible substrate for CapTP on https

stay wrote:
> http://blog.appenginefan.com/2009/07/faux-sockets-for-rich-java-clients.html

The details of the protocol this is using are buried in the source code
(http://code.google.com/p/aeftools/source/browse/#svn/trunk/src/java/com/appenginefan/toolkit/common).

It doesn't look particularly complicated, but I have to say I'm skeptical
that you'd really be saving much time by reverse-engineering and documenting
[*] this properly, compared to coming up with something similar yourself.

[*] The javadoc doesn't say anything useful; javadoc hardly ever does.

--

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
e-lang mailing list
e-lang <at> mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 0 comments |
headers
David Wagner | 12 Aug 2009 05:45
Picon
Favicon

CVE-2009-2475

Does anyone know anything more about the Java vulnerability
CVE-2009-2475?  The only information I could find (see below)
refers to problems with mutable static variables.

Would Joe-E have prevented these flaws?  (Joe-E bans mutable
static variables.)

Several, potential information leaks were found in various mutable static
variables. These could be exploited in application scenarios that execute
untrusted scripting code.

https://bugzilla.redhat.com/show_bug.cgi?id=513215

Sun Java SE 5.0 before Update 20 and 6 before Update 15,
and OpenJDK, might allow context-dependent attackers to obtain
sensitive information via vectors involving static variables that
are declared without the final keyword, related to (1) LayoutQueue,
(2) Cursor.predefined, (3) AccessibleResourceBundle.getContents,
(4) ImageReaderSpi.STANDARD_INPUT_TYPE, (5)
ImageWriterSpi.STANDARD_OUTPUT_TYPE, (6) the imageio plugins, (7)
DnsContext.debug, (8) RmfFileReader/StandardMidiFileWriter.types, (9)
AbstractSaslImpl.logger, (10) Synth.Region.uiToRegionMap/lowerCaseNameMap,
(11) the Introspector class and a cache of BeanInfo, and (12) JAX-WS,
a different vulnerability than CVE-2009-2673.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2475
Permalink | Reply | 1 comment |
headers
David-Sarah Hopwood | 12 Aug 2009 09:23
Favicon
Gravatar

Re: CVE-2009-2475

David Wagner wrote:
> Does anyone know anything more about the Java vulnerability
> CVE-2009-2475?  The only information I could find (see below)
> refers to problems with mutable static variables.
> 
> Would Joe-E have prevented these flaws?  (Joe-E bans mutable
> static variables.)

Yes, it would (if the code in question were either Joe-E, or not exposed
by taming decisions).

> Several, potential information leaks were found in various mutable static
> variables. These could be exploited in application scenarios that execute
> untrusted scripting code.

I'm not sure why this is referred to only as an information leak; it's
both an information leak and an integrity issue (since obviously, code
using these variables cannot be defensively consistent if they are
globally mutable).

Any public static non-final variable in a Java API is necessarily a bug.
So are static variables that are final but reference mutable objects,
when access to those objects is not controlled by some security check.

--

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
e-lang mailing list
e-lang <at> mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 0 comments |
headers
Kevin Reid | 17 Aug 2009 18:55
Picon
Gravatar

Re: Data-E: Removing fixed literal type set

On Jun 3, 2009, at 1:03, Kevin Reid wrote:

> The buildLiteral/1 message to Data-E builders is renamed buildAtom/1.
>
> A Data-E builder specifies the kinds of objects it will accept as
> atoms, by a guard which can be retrieved from it. (We need to choose
> the verb for this.)

I thought I had posted this before, but apparently not: we have chosen  
atomType/0, by analogy with collections' keyType and valueType.

> This does not introduce a large compatibility problem (from
> differences in what is considered an atom) because: In most builder/
> recognizer compositions, either the recognizer or the builder is
> deSubgraphKit.  ...
>
> deSubgraphKit's recognizer only invokes the builder's buildAtom if the
> object under consideration is Data (i.e. authorityless), and
> deSubgraphKit's builder only accepts Data as atoms. This ensures that
> Data-E does not carry authority other than that explicitly described
> by uses of the defined exits.

I have implemented this scheme in Caja-CapTP, and I just realized a  
certain bug resulted from the fact that I did not implement the  
abovementioned Data requirement: under that condition, if a  
deSubgraphKit recognizer is connected to a deSubgraphKit builder, _it  
always just passes the root object through_!

This is not good, as joined deSubgraphKits are useful for deep-copying  
and translation.

Implementing the Data restriction would work for this particular case,  
but I am thinking that, in general, the deSubgraphKit should have its  
recognizers _parameterized_ with a guard restricting what it will pass  
to buildAtom. This way the recognizer's client (the emitter of a Data- 
E stream) can control exactly what literal objects may be sent to the  
builder.

Does this seem reasonable? Should the subgraph builder also be  
parameterized with the atom guard?

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 0 comments |

Gmane