core_sign_update: use pkcs11 openssl engine

[tormath1]

To be tested with an actual payload.
SDK: http://jenkins.infra.kinvolk.io:8080/job/container/job/sdk/1275/cldsv/

TODO:

• add the openssl configuration to consume the PCKS11 engine (https://github.com/OpenSC/libp11#using-the-engine-from-the-command-line) (see: baselayout: add openssl configuration required to sign from the SDK baselayout#33)
• include the "generate_payload" in this repo ? NOTE: we need to update the key URI to pass the pin-code
• include the "download_payloads" in this repo?
• provide some documentation (like the /usr/sbin/pcscd daemon that needs to run in foreground)
• remove the hack around USB group for acct-user/pcscd (see the comment: core_sign_update: use pkcs11 openssl engine #1149 (comment))

The workflow would be the follow: (see: https://github.com/flatcar/flatcar-maintainer-private/pull/9)

• start the SDK
• start the pcscd daemon
• plug the device
• ./generate_payloads alpha:3815.0.0 ...

[pothos]

+1 for adding download_payloads/generate_payload to this repo. (What I don't like is making it mandatory to run inside the SDK because of of common.sh)

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/7628587794

[pothos]

start the pcscd daemon

Inside the SDK or can I use the one from the host? Would it conflict with the one from the host? That was the case before and one had to manually stop it for successful signing.

[pothos]

• ./download_payloads alpha:3815.0.0 ...

• ./generate_payloads ./data/ keys (with a for loop on the releases in ./data/)

In the end a big wrapper would be nice that downloads and uploads.

[tormath1]

start the pcscd daemon

Inside the SDK or can I use the one from the host? Would it conflict with the one from the host? That was the case before and one had to manually stop it for successful signing.

@pothos I just checked, it conflicts indeed:

00000000 [140694532543296] ccid_usb.c:683:OpenUSBByName() Can't claim interface 1/9: LIBUSB_ERROR_BUSY

For this to work, one has to use the daemon from the SDK (and not from the host). That's also the idea behind: no need to pull dependencies on your own machine.

[pothos]

Looks good!

[pothos]

Let's merge and then remove the scripts from flatcar-build-scripts, otherwise things can get out of sync

[krnowak]

I assume that the scripts work. The changes in portage-stable and coreos-overlay look good. The baselayout will need to have its commit ID updated, of course.

One question though: why putting download_payloads script in the data subdirectory? The generate payload scripts could just create the directory and call download_payloads from there.

[tormath1]

I assume that the scripts work. The changes in portage-stable and coreos-overlay look good. The baselayout will need to have its commit ID updated, of course.

One question though: why putting download_payloads script in the data subdirectory? The generate payload scripts could just create the directory and call download_payloads from there.

It's because the download_payloads can be used separately from the generate_payload to previously download the payloads if you work in air gapped environment (as recommended when generating the release payloads).