Bug 108107 - Remove hardcoded reference to SunJCE provider in c.a.kernel.security.Crypto
Summary: Remove hardcoded reference to SunJCE provider in c.a.kernel.security.Crypto
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
(Show other bugs)
Version: nightly
Hardware: All Linux
Target Milestone: ---
Assignee: Vadim Nasardinov
QA Contact: Jon Orris
Depends On:
Blocks: 106481
TreeView+ depends on / blocked
Reported: 2003-10-27 18:05 UTC by Daniel Berrange
Modified: 2007-04-18 16:58 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Daniel Berrange 2003-10-27 18:05:12 UTC
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


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:

Steps to Reproduce:
1. N/a

Additional info:

Comment 1 Vadim Nasardinov 2003-12-22 22:23:59 UTC
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:


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 22:52:00 UTC
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.