Bug 108107
| Summary: | Remove hardcoded reference to SunJCE provider in c.a.kernel.security.Crypto | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Web Application Framework | Reporter: | Daniel Berrangé <berrange> |
| Component: | other | Assignee: | Vadim Nasardinov <vnasardinov> |
| Status: | CLOSED RAWHIDE | QA Contact: | Jon Orris <jorris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | nightly | CC: | kwade |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-01-26 20:57:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 106481 | ||
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. Documentation accurate, minor fixes to SGML (<screen> and <computeroutput> should be flush left on separate lines, as per RH docs standards). |
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: