Specification Lead: Ronald Toegl, IAIK, Graz University of Technology
Copyright © 2011 IAIK, Graz University of Technology.
This TEXT document is citing material from the JSR 299 TCK documentation and therefore licensed under the the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
This guide describes how to download, install, configure, and run the Technology Compatibility Kit (TCK) used to verify the compatibility of an implementation of the JSR-321: Trusted Computing API for Java specification.
The JSR321 TCK is built atop the JUnit Test framework to define test cases and JT Harness as GUI test management tool. It is targeted for Java SE.
The JSR321 TCK is provide under the GNU Public License v2 with Classpath exception.
This guide is for implementors of JSR321 technology to assist in running the test suite that verifies the compatibility of their implementation.
Before reading this guide, you should familiarize yourself with the Trusted Computing Group's (TCG) specifications regarding the Trusted Platform Module (TPM), version 1.2 and the TCG Software Stack, version 1.2.
The JSR321 TCK must be used to ensure that your implementation conforms to the JSR321 specification. This part introduces the TCK, gives some background about its purpose, states the requirements for passing the TCK and outlines the appeals process.
In this part you will learn where to obtain the JSR321 TCK and supporting software. You are then presented with recommendations of how to organize and configure the software so that you are ready to execute the TCK.
Finally, it discusses the reporting provided by the TCK.
A TCK, or Technology Compatibility Kit, is one of the three required pieces for any JSR (the other two being the specification document and the reference implementation). The TCK is a set of tools and tests to verify that an implementation of the technology conforms to the specification. The tests are the primary component, but the tools serve an equally critical role of providing a framework and/or set of SPIs for executing the tests.
A TCK is entirely implementation agnostic. Ideally, it should validate assertions by consulting the specficiation's public API.
The goal of any specification is to eliminate portability problems so long as the program which uses the implementation also conforms to the rules laid out in the specification.
Executing the TCK is a form of compatibility testing. It's important to understand that compatibility testing is distinctly different from product testing. The TCK is not concerned with robustness, performance or ease of use, and therefore cannot vouch for how well an implementation meets these criteria. What a TCK can do is to ensure the exactness of an implementation as it relates to the specification.
Compatibility testing of any feature relies on both a complete specification and a complete reference implementation. The reference implementation demonstrates how each test can be passed and provides additional context to the implementor during development for the corresponding assertion.
Java platform compatibility is important to different groups involved with Java technologies for different reasons:
The JSR321 specification goes to great lengths to ensure that programs written for Java SE are compatible and that the TCK is rigorous about enforcing the rules the specification lays down.
The JSR321 TCK is designed as a portable, configurable and automated test suite for verifying the compatibility of an implementation of the JSR321 specification. The test suite is provided as suite of JUnit test cases and helper functionalities that allows integration in the JT Harness test framework.
The TCK provides a suite of tests that cover the JSR321 API specification. It consists of the following folders and files:
../jsr321-tck/ | ---> classes/ | | | ---> javax.trustedcomputing.tpm/** | | | ---> (various test cases) ---> java/ | | | ---> javax.trustedcomputing.tpm/** | | | ---> (the java files for the test cases) ---> lib/ | |---> (dependencies of the test tools and their licences) | | ---> jsr321-tck-utils.jar (helper classes for the test suite) testsuite.jtt (TestSuite configuration for JT Harness) example.AbstractTestCase.properties (an example configuration file) example.run.sh (a template start script for Linux) example.run.cmd (a template start script for Windows) iaik_run.sh (a pre-configured start script for IAIK's RI) (not normative) iaik_run.cmd (a pre-configured start script for IAIK's RI) (not normative) README.txt (this file)
The JSR321 TCK has been tested on following platforms:
While the JSR321 TCK is rigorous about enforcing an implementation's conformance to the JSR321 specification, it's reasonable to assume that an implementor may discover new and/or better ways to validate the assertions. This chapter covers the appeals process, defined by the Specification Lead, IAIK. Graz University of Technology, which allows implementors of the JSR-321 specification to challenge one or more tests defined by the JSR321 TCK.
The appeals process identifies who can make challenges to the TCK, what challenges to the TCK may be submitted, how these challenges are submitted, how and by whom challenges are addressed and how accepted challenges to the TCK are managed.
Following the increasing transparency in the JCP, implementors are encouraged to make their appeals public, which this process facilitates. The JCP community should recognize that issue reports are a central aspect of any good software and it's only natural to point out shortcomings and strive to make improvements. Despite this good faith, not all implementors will be comfortable with a public appeals process. Instructions about how to make a private appeal are therefore provided.
Any implementor may submit an appeal to challenge one or more tests in the TCK.
Any test case, test case configuration, and other resources may be challenged by an appeal.
What is generally not challengable are the requirements made by the specification. The specification document is controlled by a separate process and challenges to it should be handled through the JSR-321 EG by contacting the specification lead.
2.3. How these challenges are submitted?
To submit a challenge, a new entry should be created in the Wiki of the jsr321 project at java.net. The appellant should provide a title, summary, list of suggested changes including Java code or patch-file and a successful test run protocol of the changed TCK which details the hardware and software environment used.
A message should be sent to the specification lead to inform of the appeal and the Wiki page details can be found.
Any communication regarding the issue should be pursed in the comments of the filed issue for accurate record.
To submit an issue in the JBoss JIRA, you must have a (free) JBoss.com member account. You can create a member account using the on-line registration.
If you wish to make a private challenge, you should follow the above procedure, setting the Security Level to Private. Only the issue reporter, TCK Project Lead and designates will be able to view the issue. 2.4. How and by whom challenges are addressed?
The challenges will be addressed in a timely fashion by the CDI TCK Project Lead, as designated by Specification Lead, Red Hat Middleware LLC. or his/her designate. The appellant can also monitor the process by following the issue report filed in the CDITCK project of the JBoss JIRA.
The current TCK Project Lead is listed on the CDITCK Project Summary Page on the JBoss JIRA. 2.5. How accepted challenges to the TCK are managed?
Accepted challenges will be acknowledged via the filed issue's comment section. Communication between the CDI TCK Project Lead and the appellant will take place via the issue comments. The issue's status will be set to "Resolved" when the TCK project lead believes the issue to be resolved. The appellant should, within 30 days, either close the issue if they agree, or reopen the issue if they do not believe the issue to be resolved.
Resolved issue not addressed for 30 days will be closed by the TCK Project Lead. If the TCK Project Lead and appellant are unable to agree on the issue resolution, it will be referred to the JSR-299 specification lead or his/her designate.
Periodically, an updated TCK will be released containing tests altered due to challenges. No new tests will be added. Implementations are required to pass the updated TCK. This release stream is named 1.0.z where z will be incremented.
Additionally, new tests will be added to the TCK improving coverage of the specification. We encourage implementations to pass this TCK, however it is not required. This release stream is named 1.y.z where y > 0.