The motivation behind retaining this backwards compatibility, at least
now, is that it's actually non-trivial to revert these code changes for
a given release.
The `sign.sh` changes can easily be changed, but the `core_sign_update`
code is included in the update-specific "au_zip" file. Replacing that is
a little more fiddly.
Since it's possible we'll still want to revert to the previous signing
behavior, make it so the update payload (namely core_sign_update) should
work both under the previous `sign.sh` script, and when using the new
one.
We currently sign with both a devel key and a prod key. The devel key is
insecure and need not be included on a smartcard, so it makes sense to
leave it be on disk.
However, the previous commit's padding changes removed this legacy
method of signing.
For simplicity, simply re-introduce the old logic conditionally based on
whether it's a smartcard or not.
Alternate options could be using `-pkcs` instead of `-raw` for both
keys, but that is a more intricate change I'd be less confident in
making.
Sign updates using private keys on smartcards. This involves changing the
padding approach - rather than including the padding in the hash, ask the
card to generate the padding itself, since the card will refuse to sign
pre-padded material. Use + as a key separator rather than : as the PKCS#11
URI includes colons.
Takes a filesystem image and generates a update.gz that is signed by N
provided private keys and verified against the N public keys. This is so
we can do keyrotations.
