|Skip Navigation Links|
|Exit Print View|
|Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library|
IPS package manifests can be signed, with the signatures becoming part of the manifest.
Signatures are represented as actions just as all other manifest content is represented as actions. Since manifests contain all the package metadata (such as file permissions, ownership, and content hashes), a signature action that validates that the manifest has not be altered since it was published is an important part of system validation.
The signature actions form a tree that includes the delivered binaries such that complete verification of the installed software is possible.
In addition to validation, signatures can also be used to indicate approval by other organizations or parties. For example, the internal QA organization could sign manifests of packages once the packages are qualified for production use. Such approvals could be required for installation.
A manifest can have multiple independent signatures. Signatures can be added or removed without invalidating other signatures that are present. This feature facilitates production handoffs, with signatures used along the path to indicate completion along the way. Subsequent steps can optionally remove previous signatures at any time.
A signature action has the following form:
signature hash_of_certificate algorithm=signature_algorithm \ value=signature_value \ chain="hashes_of_certificates_needed_to_validate_primary_certificate" \ version=pkg_version_of_signature
The payload and chain attributes represent the packaging hash of the PEM (Privacy Enhanced Mail) files, containing the x.509 certificates which can be retrieved from the originating repository. The payload certificate is the certificate that verifies the value in value. The value is the signed hash of the message text of the manifest, prepared as discussed below.
The other certificates presented need to form a certificate path that leads from the payload certificate to the trust anchors.
Two types of signature algorithms are supported:
The first type of signature algorithm is the RSA group of algorithms. An example of an RSA signature algorithm is rsa-sha256. The string after the hyphen (sha256 in this example) specifies the hash algorithm to use to change the message text into a single value the RSA algorithm can use.
The second type of signature algorithm is compute the hash only. This type of algorithm exists primarily for testing and process verification purposes and presents the hash as the signature value. A signature action of this type is indicated by the lack of a payload certificate hash. This type of signature action is verified if the image is configured to check signatures. However, its presence does not count as a signature if signatures are required. The following example shows a hash only signature action:
signature algorithm=hash_algorithm value=hash \ version=pkg_version_of_signature
Publishing a signed manifest is a two step process. This process leaves the package intact, including its time stamp.
Publish the package unsigned to a repository.
Update the package in place, using the pkgsign command to append a signature action to the manifest in the repository.
This process enables a signature action to be added by someone other than the publisher without invalidating the original publisher's signature. For example, the QA department of a company might want to sign all packages that are installed internally to indicate they have been approved for use, but not republish the packages, since republishing would create a new time stamp and invalidate the signature of the original publisher.
Note that using the pkgsign command is the only way to publish a signed package. If you publish a package that already contains a signature, that signature is removed and a warning is emitted. The pkgsign(1) man page contains examples of how to use the pkgsign command.
Signature actions with variants are ignored. Therefore, performing a pkgmerge on a pair of manifests invalidates any signatures that were previously applied.
Note - Signing the package should be the last step of the package development before the package is tested.