Import wildcards harmful?

Ihab Awad writes:
>I am wondering if import wildcards (and, more generally, any import
>mechanism that grants the servant module the ability to insert things into
>the client's namespace) is inherently unsafe. In Joe-E, assume that I wrote
>code to do --
>
>  import com.good.*;
>  import com.evil.*;
>
>  x = new Foo(); // comes from Good.com
>
>If there also existed a "com.evil.Foo", the Java compiler would flag this as
>an error. However, if Good.com dropped support for "com.good.Foo", and
>Evil.com caught wind of that and quickly rolled out their own "com.evil.Foo",
>there could be a window of time when instances of my code "in the wild"
>would be vulnerable to the resulting substitution attack.
>
>How does that map to the threat model of Joe-E? Is it a concern? Should
>Joe-E reject all import wildcards?

Good question.  A few years ago, Marc Stiegler posted a set of "best
practices" for writing capability-style code.  One of his suggestions was
to avoid wildcards in import-statements.  In addition to the ambiguity
issue you raise, MarcS also pointed out that listing all imports
explicitly may make security review easier, by making it easier to see
what classes the code uses.  That seemed like reasonable advice to me
on the surface, though I don't do much Java programming so I'm probably
not in a good position to evaluate it.

Personal opinion: The Joe-E verifier should not reject wildcards in
import-statements.  Roughly speaking, the design principle we try to
follow is that the Joe-E verifier should only reject programming idioms
that are incompatible with object-capability reasoning.  We don't
try to enforce "good programming practices" in the Joe-E verifier.
(For instance, in many cases it's a good practice to mark all instance
fields as private and add public getters/setters as needed, rather than
marking instance fields as public.  But Joe-E doesn't reject classes
with public fields.)

Instead, I've had in my mind that the right way to do this is to build a
separate "capability lint" tool.  The caplint tool would scan your code
for dangerous programming practices and coding patterns that tend to
violate "the capability way", and warn you about everything it finds in
your code.  I've been collecting a list of things such a caplint might
check, and import wildcards is on that list.  If we got really ambitious,
we can imagine that the caplint might offer to refactor your code for you
by automatically by transforming the wildcarded imports into wildcard-free
explicit import statements.  But right now there are no plans to build a
caplint any time soon: we've got other things that are a higher priority.
In the meantime, my recommendation is that Joe-E programmers should try
to avoid known types of "bad style", even if we don't have a caplint tool
to help warn them when they write bad code.

Does this make sense to you?