If a package has a signature, the signature can be replaced or a new signature can be added keeping the old one.
Currently, swbis does not have a utility to make this easy, however, one is planned. The swinstall and swverify command currently support multiple signatures.
To replace the signature, all that is required is to replace the data part of the <path>/catalog/dfiles/signature file or add a new archive member, using the same tar header, placing it before or after the existing signature member.
The signature itself must be formatted in a particular way and have a length in bytes that matches its tar header, this is currently 1024 bytes. Every signature must have the same tar header (i.e. same name) and this tar header is stored in the <path>/catalog/dfiles/sig_header file.
Hence, to make a new signature member, take the data part of <path>/catalog/dfiles/sig_header (512 bytes) and append the 1024 bytes of the properly formatted signature, replace or add these 1536 bytes in the archive (this currently must be done by manually splitting the file into pieces, then concatenating it back together or by using a binary editor).
Fortunately, swbis does have a utility to reproduce the signed data. gpg and dd will be used to make a signature and format it like this:
# First, grab the sig_header
tar zxpf somepackage-1.0.tar.gz -O \*/catalog/dfiles/sig_header |
dd bs=512 count=1 of=/tmp/newsig
# Now, make the new signature
# Note: 'swverify -WC' writes the signed data to stdout
swverify -WC <somepackage-1.0.tar.gz |
gpg --armor -sb -o - | dd bs=1024 conv=sync count=1 >>/tmp/newsig
For example, a package with two (2) signatures looks like this:
somepackage-1.0/catalog/
somepackage-1.0/catalog/INDEX
...
somepackage-1.0/catalog/dfiles/sig_header
somepackage-1.0/catalog/dfiles/signature
somepackage-1.0/catalog/dfiles/signature
...
Since all but the last signature is lost when unpacked, the last signature should be the considered the primary one.