2525N/A Chapter 11 - signing packages.
2525N/AOne important consideration in the design of IPS was being able to
2525N/Avalidate that the software installed on the customer's machine was
2525N/Aactually as originally specified by the publisher. This ability to
2525N/Avalidate the installed system is key for both the customer and the
2525N/ATo support this validation, manifests can be signed in IPS with the
2525N/Asignatures becoming part of the manifest. Signatures are represented
2525N/Aas actions like all other manifest content. Since manifests contain
2525N/Aall the package metadata - file permissions, ownership, content
2525N/Ahashes, etc, a signature action that validates that the manifest has
2525N/Anot be altered since it was published is an important part of system
2525N/Avalidation, and insures that the package has not be altered.
2525N/AThe signature actions form a Merkle, or hash, tree that includes the
2525N/Adelivered binaries such that complete verification of the installed
2525N/Asoftware is possible. There are other uses for manifest signing
2525N/Abeyond validation; signatures can also be used to indicate approval by
2525N/Aother organizations or parties. For example, the internal QA
2525N/Aorganization could sign manifests of Solaris packages once they had be
2525N/Adetermined to be qualified for production use; policy settings could
2525N/Amandate such approvals prior to installation.
2525N/AAs a result, a useful characteristic for signatures is to be
2525N/Aindependent of other signatures in a manifest; it was decided
2525N/Anecessary to support the addition (or removal) of signatures (but not
2525N/Aother actions) in a manifest without invalidating the other signatures
2525N/Athat might be present. This feature also facilitates production
2525N/Ahandoffs, with signatures used along the path to indicate completion
2525N/Aalong the way; subsequent steps can optionally remove previous
2525N/Asignatures at any time without ill-effect.
2525N/ASignature actions look like this:
2525N/Asignature <hash of certificate> algorithm=<signature algorithm> \
2525N/A value=<signature value> \ chain="<hashes of certs needed to
2525N/A validate primary certificate>" \ version=<pkg version of
2525N/Ahash of the pem file(s) containing the x.509 certificate(s)
2525N/Adownloadable from the originating repository; the value is the signed
2525N/Ahash of the manifest's message text, prepared as discussed below. The
2525N/Apayload certificate is the certificate which verifies the value in
2525N/Acertificate path that leads from the payload certificate to the trust
2525N/Aanchor(s) that was established as part of the publisher configuration.
2525N/ATwo types of signature algorithms are currently supported. The first
2525N/Ais the rsa group of signature algorithms; an example is "rsa-sha256".
2525N/AThe bit after the dash specifies the hash algorithm to use to change
2525N/Athe message text into a single value the rsa algorithm can use.
2525N/AThe second type of signature algorithm is compute the hash only. This
2525N/Atype of algorithm exists primarily for testing and process
2525N/Averification purposes and presents the hash as the signature value. A
2525N/Asignature action of this type is indicated by the lack of a payload
2525N/Acertificate hash. This type of signature action is verified if the
2525N/Aimage is configured to check signatures. Its presence however does
2525N/Anot count as a signature if signatures are required.
2525N/Asignature algorithm=<hash algorithm> value=<hash> \ version=<pkg
2525N/AAdditional signature types (pgp, for example) may be added in the
2525N/AAdditional metadata can be added to a signature if desired, as with
2525N/Aany other action; such metadata is protected by that signature.
2525N/APolicies may be set for the image or for specific publishers. The
2525N/Apolicies include ignoring signatures, verifying existing signatures,
2525N/Arequiring signatures, and requiring that specific common names must be
2525N/Aseen in the chain of trust. Other policies may be added in the
2525N/APublishing a signed manifest is a two step process. First, the
2525N/Apackage is published unsigned, to a repository. The package is then
2525N/Aupdated in place, using pkgsign, appending a signature action to the
2525N/Amanifest in the repository but leaving the package, including its
2525N/Atimestamp, intact. This process allows a signature action to be added
2525N/Aby someone other than the publisher without invalidating the original
2525N/Apublisher's signature. For example, the QA department of a company
2525N/Amay want to sign all packages that are installed internally to
2525N/Aindicate they have been approved for use, but not republish the
2525N/Apackages which would create a new timestamp and invalidate the
2525N/Asignature of the original publisher.
2525N/ANote that pkgsign is the only way to publish a signed package. If one
2525N/Aattempts to publish a package already containing a signature, that
2525N/Asignature is removed with a warning. The pkgsign man page contains
2525N/Aexamples of how to use pkgsign.