Programatica Tools

Directory tools/evman

The README file is displayed below the directory index.
NameLast modifiedSize
Parent Directory  -
Makefile2005-10-11 01:09 1.9K
cert.sh2005-03-22 23:08 6.5K
functions.sh2006-05-24 00:27 3.3K
icons/2004-09-01 23:49 -
install.sh2003-07-16 00:12 182
servers/2006-02-08 08:01 -
validation.sh2005-01-20 23:15 1.2K

What is in this directory (evman)

This directory contains files relating to evidence (certificate) management, in particular the command line tool cert and the implementation of the certificate servers.

The code for certificate managment provided here is mostly inteded to serve as glue between the main Programatica tools (pfe) and external tools, such as theorem provers, and is implemented as shell scripts (but perhaps it would be better to do all of this in Haskell...).

This is the main command-line based certificate management tool. It is also used from pfebrowser, so interaction with the user has to be designed so that it works both from the command line and in the GUI provided by pfebrowser.

Some generic certificate management functionality is implemented directly in, while certificate type specific work is delegated to scripts in the servers subdirectory. At present, two functions are delegated: new to create new certificate and validate to validate certificates.,
Auxiliary shell functions used by many of the certificate management scripts.
Guess what...


A collection of certificate icons provided by Mark P. Jones.
This directory contains implementation of servers for specific certificate types, with one subdirectory per server.

Certificate server implementation

The following is required for each certificate server (some of these things might be created automatically, using the Makefile):
  1. Certificate type description file: server.attr (more details are given below),
  2. Certificate icons: invalid.gif, unknown.gif, valid.gif,
  3. The program new for creating new certificates, invoked from,
  4. The program validate for validating certificates, invoked from
The existing servers have new and validate programs that are implemented as fairly short shell scripts. An easy way to create a new server is to copy and modify an existing one. When common patterns emerge, functions can be moved to the or files.

There is no requirement that the programs new and validate are implemented as shell scripts. All that is required is that the files are executable and behave as expected.

Certificate files maintained by certificate servers

Certificate servers are expected to create and maintain a number of files for each certificate:

FileWhat it is used for
cert.attrs This file holds various certificate attributes. Attribute files and certificate attributes are described in more detail below.
These files are datestamps to indicate when the certificate was last marked valid or invalid. This helps tools quickly determine if a certificate is valid, invalid or if a more thorough test is needed to determine its status.
deps This file records a signature of the parts of the source code that the certified assertion depends on. It can be generated with the command
pfe tasig M.A >.../deps
It allows tools to tell the difference between source code changes that affect the validity of an assertion from irrelevant changes, so that needless revalidation can be avoided. It also allows the I_say_so certificate server to use the command pfe tadiff ... to present a list of relevant changes to the user.
srclist.txt This file caches the list of source files containing code that the certified assertion depends on. Together with the valid and invalid datestamp files, it is often possible to determine the validity of a certificate just by consulting the last modification date of files. It is used by the command cert ls.
output.txt This is the standard place for diagnostic output from the certificate server. The user can consult this, for example to find out why certificate validation failed.

Attribute files

Both servers and the certificates they create are described by a set of attributes that are stored in attribute files. There are both Haskell functions and shell script functions to parse attribute files.

Attribute file format

Attribute files use a textual file format for association lists. Each line in an attribute file may specify a binding of a tag string to a value string using a single colon to separate the two. If the colon is omitted, then a value of "" is assumed. Leading whitespace at the beginning of each line and preceding the value (i.e., after the first, if any, colon) is ignored. Lines containing only whitespace, or in which the first non-whitespace character is a '#' are treated as comments. (Despite this, we do not intend attribute files to be a human-readable format under normal circumstances.)

Here is a sample attribute file:

 # This is a comment
 foo: your name here!
 # here is a line with no value ...
 set filec
 # if the same tag is used more than once, then
 # we simply get multiple attribute values with
 # the same tag.

Server attributes

Certificate server attributes are stored in a file called server.attr in the server's directory. For an example, see servers/Alfa/server.attr

The tools currently assumes the following attributes to be present:

Attribute nameAttribute meaning
name The name of the server
description A one-line explanation of what kind of certificates the server creates.
attribute Certificate attribute description. This can be given any number of times to describe what user editable attributes are present in certificates created by this server. (These have a specific syntax that should be documented in more detail!)

Additional fields can be present.

Certificate attributes

Certificate attributes are (to some extent) defined by the different certificate servers. However, some attributes are expected to have the same meaning in all certificates:

Attribute nameAttribute meaning
type The name of the server that created the certificate.
conc Conclusion. This is the name of the assertion that the certificate serves as evidence for. It should be an unqualified assertion identifer. (This is not meaningful in all certificate types.)
hyp Hypotheses. This is either .. or a list of qualified identifiers. A more detailed description is given below.
Names of auxiliary files used to establish the validity of the certificate. For example, for Alfa certificates, the name of the file containing the proof is recorded in the attribute file/proof.

Additional fields can be present.


For certificates that certify a sequent hyp|-conc, the hyp has the following forms:
Authors: various
Contact: Thomas Hallgren