The Wayback Machine - https://web.archive.org/web/20070516132418/http://openjdk.java.net:80/groups/security/

The Security Group

The Security group is comprised of developers interested in the design, implementation, and maintanence of Security components.

Introduction

The term "Security" has broad meanings and interpretations. It spans a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. The security component thus comprises a large set of APIs, tools, and implementations of commonly-used security algorithms and protocols.

As security concepts such as permissions are tightly interwoven throughout the entire Java source code, these component pages do not address issues in the other primary component areas (language features and virtual machine implementations, core libraries, graphics subsystems, hotspot, serviceability, etc). For a more detailed treatment, please see the corresponding component pages.

The primary emphasis of these pages is to explore the core security components source bases, and hopefully, get developers up to speed quickly.

What's Included...and What's Not...

The Java security components have been developed and expanded over the years, so the hierarchy may seem complicated simply due to the large number of source files and directories. But the files generally follow fairly straightforward patterns.

What's Included...

Almost all of the security component source code is included in the OpenJDK project under the j2se subtree.

As there are so many different components, they are split into many subdirectories, generally based on functional area. In most cases, the main API and implementation-independent classes live in the java/* or javax/* hierarchy, and the implementation classes are in the sun/* hierarchy. The makefiles used to build these files are generally found in the make subdirectory of the same name. Like any software projects, there are exceptions to this guidance.

What's Not Included...

Anyone who has worked in cryptography knows the import/export of cryptographic code involves complicated legal issues. At this time we are not releasing the Java Cryptography Extension (JCE) framework, the SunJCE provider, and portions of the Sun JDK providers (SunPKCS11 and MSCAPI) which make calls to the underlying cryptographic implementations (via the javax.crypto.Cipher and related classes).

The JCE framework and the SunJCE provider is available in OpenJDK via the prebuilt library files from the "Import JDK". The OpenJDK makefiles will copy the jce.jar and sunjce_provider.jar files from the JDK_IMPORT_PATH directory into the OpenJDK builds.

This is a huge hassle for us as well. We are actively working to remove these restrictions.

Building the security components

The workspace distribution MUST ALWAYS BE buildable from scratch. As the security components have interdependencies with other parts of the JDK, you should always do a successful tops-down build on any new workspace BEFORE making any changes. It will be very helpful to keep the build log, so that if any changes are not compiling, you can determine the correct makefile to use.

When you have changes that are almost ready to submit, you should delete your build directories and rebuild everything from scratch one last time, just to ensure you haven't introduced an incompatible build change or unexpected interdependency. If your changes might impact other workspaces (such as control, deploy, or install), you should build those workspaces as well. See the build instructions for more information on building the various workspaces.

As mentioned earlier, the makefiles generally follow the package hierarchy. If you make a change to java.security.KeyStore, you should go to the make/java/security and issue a make command from there.

Testing your changes

As a rule, unit tests for fixes and new functionality are pretty much mandatory. However, before submitting changes, you should run the relevent regression tests to make sure that the existing tests continue to pass. For the security component, at a minimum you should run:

The full suite will be run before your changes are placed into the source tree. However, if your changes break something, it will be a lot more work to diagnose, and then fix or back out. Do as much testing as possible.

Documentation

Community

close