COLLECTED BY
Collection:Save Page Now Outlinks
TIMESTAMPS
The Securitygroup is comprisedof developers who participate in the design, implementation, andmaintenance of Java Security components.
The current members of the Security Group arelisted in thecensus.
If you have any potential vulnerability to report, please seeOracle'sReportingSecurity Vulnerabilities page or theOpenJDKVulnerabilities page.
The term "Security" has broad meanings and interpretations. Itspans a wide range of areas, including cryptography, public keyinfrastructure, secure communication, authentication, and accesscontrol. The security component thus comprises a large set of APIs,tools, and implementations of commonly-used security algorithms andprotocols.
As security concepts such as permissions are tightly interwoventhroughout the entire Java source code, these component pages donot address issues in the other primary component areas (languagefeatures and virtual machine implementations, core libraries,graphics subsystems, hotspot, serviceability, etc). For a moredetailed treatment, please see the corresponding componentpages.
The primary emphasis of these pages is to explore the coresecurity components source bases, and hopefully, get developers upto speed quickly.
The Java security components have been developed and expandedover the years, so the hierarchy may seem complicated simply due tothe large number of source files and directories. But the filesgenerally follow fairly straightforward patterns.
All of the security component source code is included in theOpenJDK project under thejdk subtree. As there are somany different components, they are split into many subdirectories,generally based on functional area. In most cases, the main API andimplementation-independent classes live in thejava/*orjavax/* hierarchy, and the implementation classesare in thesun/* hierarchy. The makefiles used tobuild these files are generally found in themakesubdirectory of the same name. Like any software projects, thereare exceptions to this guidance.
src/share/classes/java/securitysrc/share/classes/sun/securityThe majority of the core security classes live in these twomajor subdirectories (access control, certificates, keys, messagedigests, permissions, policy, security managers, secure randomnumber generation, etc). The public API for these classes is in thejava/security hierarchy.
The Sun implementation-specific code is fairly extensive withinthesun/security hierarchy. Some subdirectories ofnote:
ec - Elliptic Curve Cryptography implementationclasses.jca - Classes to support the*.getInstance() methods. The OpenJDK implements adelayed provider selection mechanism, and the actual provider isselected as close to the actual use as possible. This mechanism isuseful for transient tokens such as smart cards.jgss - Some of the JGSS implementation classes.Other classes are below.krb5 - Some of the Kerberos implementationclasses.pkcs - Miscellaneous, general PKCS supportclasses.pkcs12 - The PKCS12 keystore implementation.provider - The "SUN" JCA provider. Many basiccryptographic services (besides encipherment) are implementedhere.provider/certpath - Certification Path builder andvalidator classes.rsa - The "SunRsaSign" provider. These classesimplement RSA-signatures and a very limited cipher algorithm. Notethat RSA is not specified for bulk encipherment, and would be tooslow anyway.smartcardio - Smard Card implementationroutines.timestamp - Routines to support certificatetimestamping.tools - The source code for thesecurity tools :keytool,policytool,andjarsigner.util - A variety of utility classes (resourcefiles, data structure manipulations, DER (ASN.1 encoding rules),and so on).validator - Various certificate validators forhttps, codesigning, CertPath, and keystores.x509 - The major implementation classes for X509certificates.src/share/classes/java/lang/SecurityException.javasrc/share/classes/java/lang/SecurityManager.javaVarious other classes of interest.
src/share/classes/javax/smartcardiosrc/share/classes/javax/xml/cryptoPublic API classes for Smart Card I/O and XML DigitalSignatures.
src/share/classes/javax/cryptosrc/share/classes/com/sun/crypto/providersrc/share/classes/sun/security/pkcs11These directories contain the core cryptography framework andSunJCE and SunPKCS11 providers. SunJCE contains Javaimplementations of many popular algorithms, and the SunPKCS11provider allows calls made through the standard Java cryptographyAPIs to be routed into a native PKCS11 library.
src/share/classes/javax/netsrc/share/classes/com/sun/net/sslsrc/share/classes/sun/security/sslsrc/share/classes/sun/net/www/protocol/httpsThe majority of the core SSL/TLS classes. Thejavax/net contains the APIs and platform-independentcode. The SSL/TLS implementation is found in sun/security/ssl. The"https" provider is directly based on the JDK "http" provider,which is located in thesun/net/www/protocoldirectory.
In JDK 1.4, the classes in the JSSE 1.x unbundledcom/sun/net/ssl package were promoted to thejavax.net.ssl package. For compatibility with JSSE 1.x, theoriginal classes remain.
src/share/classes/org/jcp/xml/dsig/internalsrc/share/classes/com/sun/org/apache/xml/internal/securityXML Digital Signature implementation classes.
src/share/classes/javax/security/authsrc/share/classes/javax/security/saslsrc/share/classes/org/ietf/jgsssrc/share/classes/com/sun/securityClasses for JAAS authentication, SASL, and JGSS.
src/share/lib/securitySecurity configuration files. (cacerts, java.policy,java.security, PKCS11 config)
The cacerts file shipped with OpenJDK is initially empty.
Note that until the cacerts files has been populated, thingslike the default httpsTrustManager will not havecertificates to trust, and will thus reject https connections.
src/solaris/classes/com/sun/securitysrc/solaris/classes/sun/securitysrc/windows/classes/com/sun/securitysrc/windows/classes/sun/securitysrc/macosx/classes/apple/securityPlatform-specific Java Code. Platform-independent code is foundinsrc/share. Platform-dependent code is found insrc/{arch} For example, theMSCAPIprovider can be found insrc/windows/classes/sun/security/mscapi.
The "solaris" directory is somewhat incorrectly named, andprobably has stuck only due to historical reasons. It should moreproperly be named "unix", as this is where the platform dependentcode for both "solaris" and "linux" live.
src/share/native/java/lang/SecurityManager.csrc/share/native/java/securitysrc/share/native/sun/securitysrc/solaris/native/com/sun/securitysrc/solaris/native/sun/securitysrc/windows/native/com/sun/securitysrc/windows/native/sun/securitysrc/macosx/native/apple/securitySimilar to the platform-specific Java code layout, native methodimplementations are found in the corresponding nativedirectories.
Note that the code currently support all versions of the variousplatforms. That includes the various releases of Solaris, Linux,Windows and Mac OS X. Consult the current supported architecturesguidelines for more information.
src/share/classes/javax/security/certsrc/share/classes/com/sun/security/certThe old JSSE 1.x certificate classes, also here only forcompatibility. These API's should be avoided in favor of thejava.security equivalent classes.
Anyone who has worked in cryptography knows the import/export ofcryptographic code involves complicated legal issues. The JCE inOpenJDK has an open cryptographic interface, meaning it does notrestrict which providers can be used.Compliance with UnitedStates export controls and with local law governing theimport/export of products incorporating the JCE in the OpenJDK isthe responsibility of the licensee.
The workspace distributionMUST ALWAYS BE buildable fromscratch. As the security components have interdependencies withother parts of the JDK, you should always do a successful tops-downbuild on any new workspaceBEFORE making any changes. Itwill be very helpful to keep the build log, so that if any changesare not compiling, you can determine the correct makefile touse.
When you have changes that are almost ready to submit, youshould delete your build directories and rebuild everything fromscratch one last time, just to ensure you haven't introduced anincompatible build change or unexpected interdependency. If yourchanges might impact other workspaces (such as control, deploy, orinstall), you should build those workspaces as well. See the buildinstructions for more information on building the variousworkspaces.
As mentioned earlier, the makefiles generally follow the packagehierarchy. If you make a change tojava.security.KeyStore, you should go to themake/java/security and issue a make command fromthere.
As a rule, unit tests for fixes and new functionality are prettymuch mandatory. However, before submitting changes, you should runthe relevent regression tests to make sure that the existing testscontinue to pass. For the security component, at a minimum youshould run:
The full suite will be run before your changes are placed intothe source tree. However, if your changes break something, it willbe a lot more work to diagnose, and then fix or back out. Do asmuch testing as possible.
