[plt-dev] trust of PLaneT packages

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Sat Mar 14 04:29:13 EDT 2009

(Emailing "plt-dev" for the smaller audience.)

I think PLaneT is a big win, but I still have a little unease about 
security of making it so easy for untrusted parties to execute arbitrary 

Some off-the-cuff ideas:

* Build degrees of code trust into the language, perhaps in parallel to 
PLT's contracts.  So, for example, code in more-trusted module M that is 
influenced by code in less-trusted module L inherits the lowest trust 
level of all the influencing code.  If there is a minimum trust level 
for the evaluation, no code with a lower trust level can be evaluated.   
Figuring out the semantics and then a usable implementation seems to me 
like a great research project, if it's not already been done.  The 
semantics work might also yield new best-practices, like "don't export 
parameters from a module."

* Sandboxes for untrusted code?

* All PLaneT server traffic through SSL, using keys distributed with 
PLT, for discouraging a casual attackers from impersonating a PLaneT 
server, such as on an open WiFi AP.

* Possibly require PLaneT packages to be signed, which would make it 
harder for an attacker to upload a new version of someone else's 
package.  Drawback is that it's a hassle barrier to people uploading 

* User interface whenever a new PLaneT package/version is about to be 
installed.  It can inform what package is being installed, show whether 
it is by an author previously trusted by the user, show what code would 
be executed just by requiring it (before calling any of its 
definitions), give a chance to inspect all the code, show diffs since 
the last version, etc.

* Have a means of "certifying" particular packages.  So human editors 
could inspect new uploads of packages, inspect the code, and add their 
signature to the code to say that they noticed no problems.  This is 
tricky from a liability standpoint.  PLaneT users could specify that 
they only want to use PLaneT packages that have been certified.

* A variation on "certifying" would be a mechanism for people to "flag" 
a particular package or version they see on PLaneT as having a security 
problem.  That avoids a liability issue, though it only lets PLaneT 
users say "only use PLaneT packages that have not been flagged," rather 
than the more restrictive "only use PLaneT packages that have been 
certified."  There could also be a mechanism for people to be informed 
when they've already installed PLaneT packages that have since been 
flagged.  There would need to be a mechanism for removing flags, and 
awareness that the flag mechanism itself creates a denial-of-service 


Posted on the dev mailing list.