launchpad-dev team mailing list archive

[Jamu Kakar <jkakar@xxxxxxxx>]

Hi Gary,

On Thu, Jul 30, 2009 at 3:32 PM, Gary Poster<gary.poster@xxxxxxxxxxxxx> wrote:
> I've had similar thoughts--i.e., maybe the import fascist should die, or
> maybe it should be made more effective.  I do think it should be one or the
> other.
>
> What do others think?  Should we kill the import fascist?  Or try to make it
> better enforce the things we care about?  Or is it fine as is?

In Landscape we have an import guardian, which is a reimplementation
of import fascist.  It differs from the fascist in that it has a
very simple policy plugin system that allows you to write import
policies easily and to configure the guardian to use the particular
policies you want.  If you're planning on making changes it might be
nice to adopt import guardian at the same time, so that we can have
a single incarnation of this kind of thing.

Something I've wondered while reading this thread is whether or not
you have a "safe importer" in Launchpad.  In Landscape, certain
functions may only be imported in browser code when using the safe
prefix.  For example:

from safe.canonical.landscape.model.main import get_person_by_id

The use of 'safe' here uses our safe importer to ensure that the
return value of get_person_by_id is wrapped in a security policy.
We have an import guardian policy that ensures that (1) safe is used
in browser code whenever an unsafe function is imported and (2) that
only a set of things from a white list is importable with safe.
This "enforce correct use of safe" is the most important thing we
get from import guardian, though we also have things like "only
allow imports defined in __all__" and so on.

Thanks,
J.