[e-lang] Newbie questions about persistence (Attn MarkM: Possible surprise-vulnerability in persistence protocol)

[Kevin Reid]

On Sep 24, 2009, at 11:11, Thomas Leonard wrote:
> On Sat, 2009-09-19 at 11:42 -0400, Mark Miller wrote:
>> On Mon, Sep 14, 2009 at 3:43 PM, Kevin Reid <kpreid at mac.com> wrote:
> [...]
>>> IMO, ScopeSetup should directly get the sealer from the
>>> PersistentKeyHolder, rather than having E-level code do it. There  
>>> may
>>> be a reason to have more configurability than that though.
>>>
>>> MarkM, is there any reason the persistence sealer should not be  
>>> widely
>>> available?
>>
>> An oversight. This is a good plan. Thomas, feel free to submit a
>> patch. Kevin, feel free to make a commitment along the lines you
>> explain above.
>
> OK, here's an attempt at a patch.

Your PersistentSealer.java has a copyright statement contains specific  
language which is not the MIT license. I would prefer that this be  
removed and there only be two-line header as in other E files, to  
avoid any future problems.

> I didn't find any documentation on the
> safej syntax, so I'm just guessing here. I didn't see any way to make
> just the getTHE_BRAND() and getTHE_SEALER() methods safe, whilst still
> allowing getTHE_UNSEALER() to be accessible using <unsafe>, so I  
> made a
> new class.

This is unnecessary complexity. Just have ScopeSetup put the sealer in  
the safeScope. Though I'm not sure what the name of the object should  
be. MarkM?

> I named the class PersistentSealer (rather than PersistenceSealer) to
> match PersistentKeyHolder.

I haven't liked the name of PersistentKeyHolder. It's not a holder of  
persistent keys, and so on. I'd rather see a consistent renaming to  
'Persistence'. MarkM?

> The seal function takes an extra "self" parameter, currently  
> ignored, in
> anticipation of Kevin's changes to the persistence protocol.


This doesn't feel appropriate to me; I can't quite say what the  
problem with it is though. It feels like something that ought to be  
'utility' not 'primitive', in particular that the unrestricted sealing  
authority should be available. but I can't quite justify that.

If nothing else, we should wait to invent such things until MarkM has  
finished chewing on the problem:
   <http://www.eros-os.org/pipermail/e-lang/2009-September/013261.html>

I also don't like that you're using a StaticMaker to be the sealer  
object, but I don't have a justification for that either.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>