phatch-dev team mailing list archive

[Robin Mills <robin@xxxxxxxxxxxxx>]

Erich

That's very interesting.  I don't know anything about keyczar -  
however it sounds like the right kind of thing.

Of course, we're jumping ahead (although now's the time to think for  
the future).  If we arrive at a time when people are publishing  
Phatch actions (or actionlists), I think we'll have to consider  
something like this.

Until then, I think what Stani's added here is really good.

Robin
http://www.clanmills.com





On Jun 17, 2009, at 7:47 AM, Erich Heine wrote:

> Robin,
>
> Thanks for expanding, your point makes much more sense now (and  
> seems much more reasonable :P ). There are some responses below  
> (after the quote):
>
> On Wed, Jun 17, 2009 at 9:10 AM, Robin Mills <robin@xxxxxxxxxxxxx>  
> wrote:
>
> However it might be nice if Python was able to refuse to run  
> scripts which don't have a valid digital certificate - and that  
> would make "alien" scripts less dangerous.
>
> So it all adds up to "The issue is with Python, not Phatch".
>
> We could put something in to check scripts against a "verified  
> good" phatch "app store". Its not that hard to do an hmac thats  
> digitally signed with the phatchdev private key. This is close to  
> trivial to write, particularly if we use a nice framework like  
> keyczar from google.  Of course then we can only verify official  
> action lists -- which is a game we may not want to play.
>
> As for where the issue lies id put equal parts of it in phatch,  
> python, and the current computing model.
>
> Phatch -- we want to run arbitrary external scripts and programs  
> which is isomorphic to running untrusted code. This desire  
> introduces the issue to begin with.
>
> Python -- no buitin code signing, no restricted shell execution  
> environment.
>
> Computing model: too much power to each process/program, no good  
> way of reliably restricting things, too much interdependence  
> resulting in all or nothing permissions models in the real world.
>
> Regards,
> Erich