This just sets the code file size to the var file size, so it gets
zero-padding without having to pipe commands together.
From: David Michael <david.michael@coreos.com>
[Rebased]
Signed-off-by: Geoff Levand <geoff@infradead.org>
And default to git instead of rsync.
git has no rate limiting and will generally be quicker after the first
run.
This does leave a bit of extra data in your local portage-stable `.git`
directory, but it doesn't seem unreasonable to me.
Note: this means we lose the "ChangeLog" file. In the rsync
repositories, that file has been generated by egencache, but the git
repository never has it checked in.
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.
We are going to restore the split-script setup from the old Jenkins
server. This ensures that the each version's release process is
actually running with scripts in the correct release branch. It
also allows branching the VM format lists.
Note that the scripts added here only cover the currently active
jobs in the main build pipeline. There is no reason to add other
jobs, since they are mostly just running a single command using a
mantle binary from its master branch.
The scripts in this repository pick up after Jenkins has set up an
environment with all parameters and credentials defined, and an SDK
was prepared and validated.
This reverts the vagrant image back to using oem-vagrant because we
don't want to break the existing images. It moves the new,
Ignition-powered virtualbox flavor of vagrant into a new image.
