Bug 108107 - Remove hardcoded reference to SunJCE provider in c.a.kernel.security.Crypto
Remove hardcoded reference to SunJCE provider in c.a.kernel.security.Crypto
Status: CLOSED RAWHIDE
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Vadim Nasardinov
Jon Orris
:
Depends On:
Blocks: 106481
  Show dependency treegraph
 
Reported: 2003-10-27 13:05 EST by Daniel Berrange
Modified: 2007-04-18 12:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-26 15:57:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-10-27 13:05:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
The initialize method in com.arsdigita.kernel.security.Crypto does a number of
checks wrt to JAAS and JCE and explicitly registers the the SunJCE provider
implementation. These steps are unneccessary in JDK 1.4.1 and now also 1.3.1
since p4 change 37346 requires that the user add JCE / JAAS libs & config to
$JAVA_HOME/jre/lib/ext. It is also bad practice to compile in references to
specific provider implementations which are intended to be pluggable. For
example, an install may prefer to use the BouncyCastle provider instead of the
Sun provider. Thus the code :

<         // install and check SunJCE
<         try {
<             java.security.Security.addProvider
<                 (new com.sun.crypto.provider.SunJCE());
<             javax.crypto.Mac.getInstance(MAC_ALGO);
<             s_log.info("Security Initializer: SunJCE installed");
<         } catch (java.security.GeneralSecurityException e) {
<             throw new InitializationException
<                 ("Could not load a required crypto algorithm:\n"+e);
<         }

should be removed, letting the user simply add

  security.provider.3=com.sun.crypto.provider.SunJCE

or equivalent, to $JAVA_HOME/jre/lib/security/java.security if required.

The c.a.packaging.Checklist program can be extended to check for the presence of
the particular algorithms WAF requires rather than hardcoding a dep on a
particular provider implementation.

NB, the following blocks of code in the same Crypto.java method are also now
redundant, being done by Checklist.java instead:

<         // check that JCE is available
<         // TODO: this check should not be needed in JDK 1.4, since JCE will
<         // be integrated into the JDK.
<         try {
<             ClassLoader.getSystemClassLoader().loadClass
<                 ("javax.crypto.Mac");
<             s_log.info("Security Initializer: JCE lib found");
<         } catch (ClassNotFoundException e) {
<             Initializer.reportMissingLibrary
<                 ("Java Cryptography Extension (JCE)", "jce.jar");
<         }
<         // check that SunJCE is available
<         try {
<             ClassLoader.getSystemClassLoader().loadClass
<                 ("com.sun.crypto.provider.SunJCE");
<             s_log.info("Security Initializer: SunJCE found");
<         } catch (ClassNotFoundException e) {
<             Initializer.reportMissingLibrary
<                 ("SunJCE cryptographic provider", "sunjce_provider.jar");
<         }


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. N/a
2.
3.
    

Additional info:
Comment 1 Vadim Nasardinov 2003-12-22 17:23:59 EST
I made the requested changes in perforce change 39030.

In order for our cookie business to continue working, users will have
add the following line to $JAVA_HOME/jre/lib/security/java.security:

  security.provider.3=com.sun.crypto.provider.SunJCE

Documented this in the install guide in change 39034.

Cc'ing Karsten so he can give 39034 a quick once-over.
Comment 2 Karsten Wade 2004-01-22 17:52:00 EST
Documentation accurate, minor fixes to SGML (<screen> and
<computeroutput> should be flush left on separate lines, as per RH
docs standards).

Note You need to log in before you can comment on or make changes to this bug.