I'm in the process of writing up my thoughts on manifest signing; here's what I have so far...
Manifests in IPS contain all the packaging metadata - file permissions, ownership, content hashes, etc, and are stored as simple text files with one line per action. When a system is checked for compliance, the manifest contents are compared to the on-disk files to determine whether or not a package is correctly installed. Given their importance, verifying that all manifests are correct and reflect the original publisher's intent is an important part of system validation. Cryptographic signatures protecting the integrity of all actions form a Merkle hash tree that includes the delivered binaries such that complete verification of the installed software is possible. There are other uses for manifest signing beyond validation; signatures can also be used to indicate approval by other organizations or parties. For example, the internal QA organization could sign manifests of Sun-delivered packages once they had be determined to be qualified for production use; images could be configured to require signed packages and thus insure that no packages As a result, it is a useful property of signatures to be independent of other signatures in a manifest; it should be possible to add (or remove) signatures (but not other actions ) in a manifest without invalidating the other signatures that are present. Incidentally, this also facilitates production hand offs, with signatures used along the path to indicate completion along the way; subsequent steps can optionally remove previous signatures at any time w/o ill-effect. This leads to the proposal of a new signature action, of the form: signature public_key=hash signature=value ... where the hash represent the packaging hash of the file containing the public key down-loadable from the originating repository; the signature is the signed sha1 hash of the manifest as discussed below, encoded in the same manner as the hash. Additional metadata can be added to the signature if desired. Computing the manifest message text: -------------------------------------- Manifests have an interesting property: the lines in a manifest may be reordered without affecting the result of installation. As a result, manifest order is unimportant and subject to change during package publication processing. It is advantageous for our manifest signing to be independent of line order, or the action ordering algorithm used for installation, as that may change over time. Straightforward C-locale alphabetical sorting of attributes within actions and across actions can be used to enforce a consistent ordering for signature purposes. In order to allow other signatures to be added or removed from a manifest, computation of the manifest hash does not include other signatures; in order to protect metadata on the signature itself, the signature being produced or verified is included in the message text at the end, aside of course from the signature attribute and value. Verification of merged signatures ---------------------------------- We produce "fat" packages (containing variants such as different architectures, debug vs non-debug kernel, etc) by producing manifests for each variant, and then merging them. Actions that are the same between variants being merge are left unmodified; those that are different receive a variant tag (see facets.txt). If it is considered useful to have signatures persist and be useful across such merges, some additional steps are required to verify such signatures after merging. Generally, signatures will be unique to their variant, thus they will be tagged with variant tags after merging. To verify signatures post-merge, the evaluation process is a little different: any variant tags present on the signature are assumed to have added afterwards. Thus, to verify the signature those variants are applied to the entire manifest, and then the message text is generated, with the key step of removing all those variant tags from each action, if present. - Bart -- Bart Smaalders Solaris Kernel Performance [email protected] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
