Skip to content

Home

Jump to bottom
kgal edited this page May 18, 2017 · 208 revisions

Protection Profile Development Getting Started

Environment Preparation

Requirements

  • A git client
  • An XML editor (preferably one that can validate against Relax NG schemas)
  • Optional (but highly recommended)
    • The make utility
    • An XSL Engine
    • The hunspell spellchecker

UNIX-derivative distribution

Creating the right environment on a UNIX-derivative platform, such as macOS, Solaris, or Linux-based, is relatively straight-forward---you just need to install the packages that correspond to the requirements listed above. For example, on a yum-based distribution, you would simply enter the following command: sudo yum install git make emacs hunspell xsltproc

Windows 10

There are a couple of options for installing the necessary requirements on a Windows 10 platform, but the easiest is probably using the Linux subsystem. Installation instructions are described here. Once this is successfully installed you need to follow the instructions listed above in the UNIX-derivative distribution section.

Adding to an Existing Project

Cloning

To edit an existing product, you must first clone the project locally. Click the green clone button on the desired project's page, as illustrated in the picture below. Clone Button Picture This should open a small window with the git URL (also illustrated in the picture). Use this to clone your project. If using the command line git client, type

git clone --recursive $GIT_URL

where $GIT_URL is the value noted above, and not the literal string. For example, for the File Encryption PP, you'd run the following command:

git clone --recursive https://github.com/commoncriteria/fileencryption.git

This will create the project in your current working directory. To build it, change your current working directory to the project's root directory and run make. This should create the final, human-readable HTML documents in the output directory. This should viewed with a JavaScript-enabled browser.

Project Structure

The PP projects in the commoncriteria group all have the same basic structure. They all have a single root directory. Under this root directory are several files and directories.

  • input/: The input directory holds the XML input files. This is where the project text goes for both the main PP and the ESR. The ESR XML is named 'esr.xml' while the main PP XML file is usually the same name as the project with an 'XML' extension.
  • output/: This is the directory the holds the HTML output files. It also has a subfolder images which is where any pictures or diagrams in the PP should go.
  • transforms/: This is where most of the logic goes that builds the PPs. It's actually a submodule, and is generally not edited by most PP contributors. To be safe, DO NOT CHANGE ANYTHING IN THIS DIRECTORY. And indeed you should be able to ignore most of these files; however, the CCProtectionProfile.rng in the schemas directory is the RNG Schema that defines the structure of the main PP input file. If you are using an RNG-aware editor, you should be able to point your editor at this to assist you to provide on-the-fly validation and in some cases tab-completion of elements and values. For more information about RNG, consult the RNG-resources in the reference section at the end of this document. Also for an API-reference style description of the elements can be found here.
  • .gitignore: This file describes other files in the project that should be ignored by git. These are usually outputfiles, and temporary or backup files generated by editors.
  • .gitmodules: File that associates the transforms project as a submodule to your project. This should be ignored.
  • LICENSE.md: Standard no-copyright disclaimer for US Government projects.
  • local/: Directory where non-content project-specific go. For instance, the hunspell spellchecker is expecting the list of whitelisted words to appear in Dictionary.txt in this directory. Project-specific XSL or RNG files, if necessary, would also go here.
  • Makefile: A make makefile that describes how to build this project. Generally it does not need to be edited; however, sometimes a PP might need to deviate from the standard build process. This might be because the input file has a non-standard name or uses a different XSL file for transformation. By defining specific variables in this file, you adjust the behavior. For instance to change the input file, you might insert the line 
     INPUT = FileEncryptionInput.xml
    at the beggining of this file. For a comprehensive list of hooks run make more-help and it will display the hooks as well as common make targets.
  • README.md: A markdown format file which should provide a basic project description. github.com will displays it when the project page is viewed.

Editing

Contributing to your project will require a shallow, but working knowledge of git. The basic work flow is something like make a couple of small changes to your document, and then committing the changes. The following git commands can be run in any directory in the project with the exception of the transform directory. This is done by marking the edited files as those to be committed for the next commit by running

git add list-of-files-to-be-committed

(or the corresponding action with a GUI-based git client). Files that are to be removed from the git project can be removed by running

git rm list-of-files-to-be-removed.

Careful---this command will remove the projects from commit and also delete them from the local filesystem (though if you had previously committed them, those versions should be recoverable). After a few, small edits, changes should be committed, and in general you can't commit too often. Running

git commit

should bring up an editor where a short description the intent of your edits should be captured. After you write this and close the editor, git will save the changes in the files noted above with your git add and git rm commands to your local directory. Running it with an -a flag will cause all files tracked by git (i.e. Not new files) that were changed to be committed.

After doing a couple of commits, the changes should be pushed back to the original; however it is important to do a couple of things before this. The first is to pull changes from the master repository and merge them with your content. This is done by running

git pull origin

Sometimes this will result it a merge, which is really just another commit. Occasionally this merge will contain conflicts, when your edits and the edits that were committed to the master since you last pulled affect the same section. When this happens the conflict sections will generally be noted thusly:

<<<<<<<<<<<<<<
One version of the edits
...
==============
The other version of the edits
...
>>>>>>>>>>>>>>

To resolve the conflict(s), delete everything except the text that is appropriate (and sometimes there are many sections that must be resolved). Once all conflicts are resolved, commit the changes, and attempt to build the project. If this is successful, you can now push the changes by running:

git push origin

Occasionally, someone may have updated since you last pull and you'll have to repeat the merge process again. It is important to remember to ALWAYS ENSURE YOUR PROJECT BUILDS BEFORE PUSHING CHANGES. Running

make git-safe-push

in the project's root directory will attempt the pull, make, push, sequence and should prevent you from inadvertently pushing broken code.

Common Make Targets

  • empty : Builds all HTML documents
  • clean : Deletes all HTML documents
  • spellcheck : Runs hunspell spellchecker
  • git-safe-push : Pulls changes from the master copy (github). Builds document and if successful pushes your changes to master.

Starting a New Project From Scratch

Cloning the Skeleton

  1. To make a new protection profile create a new repo on the git server (i.e. github.com), probably through the web interface. Note the value of its git URL which is displayed when you click the Clone or Download button on the upper left. We refer to this value as $NEW_REPO_GIT_URL.

  2. Run the following script (with the appropriate value for $NEW_REPO_GIT_URL).

git clone --bare https://github.com/commoncriteria/pp-template.git
# Make a bare clone of the repository

cd pp-template.git
git push --mirror $NEW_REPO_GIT_URL
# Mirror-push to the new repository

cd ..
rm -rf pp-template.git
# Remove our temporary local repository

  1. Do a full clone of your new project

  2. Rename the input file, currently named, input/pp-template.xml to the name of the project with xml added to it; for example, operatingsystem and application have operatingsystem.xml and application.xml input files respectively. If something was the project name it would be,

git mv input/pp-template.xml input/something.xml
  1. And start editing. The template project contains some boilerplate text. Besides adding the content, several values that are project specific are called out with the QQQQ character sequence.

Examples

If you get into trouble, it might be helpful to view other examples such as:

References

Clone this wiki locally