Security provider fallback

[Mark Wielaard]

Hi,

On Thu, 2003-03-06 at 03:30, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> The following prints a warning when non of the security provider files
> Mark> could be read or non of them contain any valid entries and falls back to
> Mark> the standard Gnu provider. If the security provider files do exist, but
> Mark> just don't contain any provider the user gets what was asked for.
> 
> Mark> This helps in situations where the security file is missing or not
> Mark> correctly installed (which seems to happen often with VMs). It also
> Mark> fixes a couple of Mauve failures that would happen if you did a make
> Mark> check without a make install first (and no old installation was
> Mark> available) like most autobuilders do.
> 
> My first inclination is not to do this.  The class library is a
> library; printing to stderr like this is a bit unfriendly.  It seems
> to violate the bounds of what a library ought to do.

Our garbage collector does it in extreme situations. But I can leave out
the warning messages. The important bit is the fallback to a default
security manager if everything goes wrong (see below). Would the patch
be OK without the warnings?

> I'd like to know more about the situation that lead up to this patch.
> I assume you ran into some trouble?  I don't like to say "no", but at
> least in this case I need to be convinced.

In some situations where the VM (not just libgcj, but also other VMs
based on GNU Classpath) is not completely/correctly installed the
security provider file (actually resource) cannot be found/loaded
correctly. If that happens there are no Security providers and a couple
of things that really need such provider or a standard algorithm breaks.
(This can be seen with Mauve if you do not yet have an installation in
your $installdir and just do a make && make check. The patch fixes the
following Mauve failures that my autobuilder shows (which doesn't do a
make install before doing make check):

FAIL: gnu.testlet.java.security.SecureRandom.Instance: uncaught exception at  number 1: java.lang.InternalError: no SHA implementation found
FAIL: gnu.testlet.java.security.SecureRandom.SHA1PRNG: found implementation (number 1)
FAIL: gnu.testlet.java.security.SecureRandom.SHA1PRNG: no implementation found (number 1)
FAIL: gnu.testlet.java.security.Security.property: uncaught exception at  number 1: java.lang.NullPointerException

Note that the fallback (and warning) only works if there no valid
security providers defined and there are errors with all security
provider resources. So if there actually is a security provider
file/resource, but it is left empty by the user then they still get what
they want (no provider and no standard algorithms).

Cheers,

Mark