[racket] PLaneT (Was: are people using untyped/snooze?)

Eli Barzilay wrote at 08/18/2011 05:40 PM:
> Two hours ago, Neil Van Dyke wrote:
>   
>> Over the years, several times I've mentioned security and stability 
>> issues involving PLaneT packages.  Now I'm wondering whether, rather 
>> than trying to get all the security right in core Racket, it would be a 
>> lot easier to make the mechanism pluggable. If pluggable, then 
>> organizations and applications could plug in their own policies for what 
>> packages and versions are permissible, from where are they gotten and 
>> how, how are they authenticated, any constraints on installing (e.g., 
>> sandboxing, requiring user to inspect and approve, etc.).  This would 
>> also make it easier for people other than the PLaneT maintainer to 
>> experiment with behavior and to upload their modified behavior as PLaneT 
>> packages for others to try.
>>     
>
> Any suggestions on how to do that?  (I'm asking about how it would
> look for users, not how to implement it.)
>   


I don't know the internals of PLaneT, so I can't really be helpful 
here.  The vague idea I had seems pretty usual: abstract the interface 
that talks to the repository, break up the existing client-side 
implementation code (e.g., fetch package from repository, install 
package, query information, etc.) into a few big chunks that can be 
called by the default plugin or composed by user-provided plugins, then 
provide the plugin interface (perhaps as one or more parameters storing 
callback procs for things like require-a-package or 
fetch-info-about-a-package or whatever is needed by PLaneT; or single 
parameter storing struct of multiple callback procs).

Then only let a non-default plugin be used if specified on command-line 
or in environment variable (specified as a module to load), and don't 
try to let it be changed dynamically.  (I can't immediately think of a 
good way it could be set in an "info.rkt", unless you're just going to 
take the "info.rkt" of the current directory or of the directory of one 
of the files on the "racket" or "raco" command line.)

One area that I would guess needs detailed thinking is things like 
whether and when we need to remember which plugin code was compiled 
with, and which plugin installed packages came through which plugin.

One of these details is that, unless PLaneT package identifiers are 
extended to specify an different authority (e.g., qualify with Internet 
domain names, somewhat like Java packages), then we can *usually* assume 
that exact package "billybob/tractor:1:=2" is the same package 
regardless of which plugin it came through.  So, if it's a package 
that's in the canonical public repository, and plugin A was getting it, 
plugin B will *usually* get a byte-for-byte identical one.  One reason 
this is a little complicated: an organization will have its own names 
for various internal-only code, and these potentially collide with 
canonical names, now, or in the future.  Another reason this is a little 
complicated, but maybe we don't have to support it: a plugin might 
change a canonical package, such as by automatically disabling all 
filesystem capabilities (poor man's capabilities), and then it's not 
byte-for-byte identical with one fetched through the default plugin.  
Regarding the former complication, I'm tentatively liking the idea of 
public packages having contributor names that do not contain ".", like 
"billybob", and non-public packages *only* having domain names with ".", 
like "mystartup.com" and "mycoolproject.mystartup.com".  (I would save 
the "." in public packages for if you decide to decentralize PLaneT, so 
that the default plugin would let you "require" from arbitrary 
authorities, and it would go to the Web site of the authority rather 
than to a centralized repository.  That's something a student could 
implement in their own plugin, for a research project, but I like the 
centralized for pragmatic reasons right now.)

-- 
http://www.neilvandyke.org/