Re: Cryptography provider

[Mark Wielaard]

Hi (CC to classpath and gnu-crypto list to keep everyone updated),

On Tue, 2002-12-03 at 17:22, Joerg Brunsmann wrote:
> --- Tom Tromey <address@hidden> wrote: 
> 
> > Mark> I thought that all java.security problems in Classpath/libgcj
> > Mark> were fixed now. What is the remaining known problem in this
> > Mark> area?
> > 
> > PR 7416.  At startup we reference a file called "GNU libgcj.security".
> > The fix is to add the VM shortname feature we talked about a couple
> > weeks ago.
> 
> The code in java/security/Security.java looks like:
> 
>   static
>   {
>     loadProviders(System.getProperty("java.home"),
>                 System.getProperty("java.vm.name"));
>     loadProviders(System.getProperty("gnu.classpath.home"), "classpath");
>   }
>   ...
>   private static void loadProviders(String dir, String vendor)
>   {
>     ...
>     String separator = System.getProperty("file.separator");
>     String secfilestr = (dir +
>                        separator + "lib" +
>                        separator + "security" +
>                        separator + vendor + ".security");
>     ...
> 
> 1. What's the rationale for loading two different provider files?
> 2. Why doesn't the 'libgcj.security' file define a provider?
> 3. What's the rationale for loading two different provider files
>    if one file doesn't define a provider?
> 4. Is the limited classpath provider used from other libgcj/classpath
>    code? If not, it might be a good idea to remove the code and give
>    the user a hint to install another fully implemented provider?

1. The idea behind this setup is that the GNU Classpath core classes
provide providers that can be used in any case. VMs that use the GNU
Classpath library might want to provide additional security providers
which are tailored to that particular VM, gcj for example might want to
add a C/C++ CNI based implementation for some algorithms.

2. It is empty but someone that installed libgcj could add a provider
later. It is just an example file.

3. See 2. And, although theoretic at the moment, multiple VMs on a
system could be sharing the standard classpath security file but you
might want to tweak a security file for a particular VM to add
additional things.

4. Yes it is used for example when a SHA1 algorithm is needed for
calculating a class SUID. And, if I have ever time to implement it, it
will be used by the java.util.jar package when verifying manifest
signatures. (Hint, hint, if someone wants something nice to hack on ...)

But GNU Classpath (and by implication libgcj) only provides support for
the basic algorithms (SHA, MD5, DSA) so we should encourage people to
install a full crypto provider. GNU Crypto would probably be the first
choice here since those developers have the coolest gcj integration at
the moment (compiles out of the box with gcj to a native shared library
and provides implementations of some algorithms optimized for gcj ahead
of time compilation) and they keep supplying nice patches to the main
security classes which I try to encourage :)

We need a similar setup for loading other property files (like for
example logging.properties) where the core GNU Classpath classes provide
generic implementations for provider classes but particular VMs might
want to add specialized providers that they package with the VM and that
might not be useful for other VMs. I think this setup is nice, but if
people have comments for improvement please say so.

Cheers,

Mark