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/
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
