Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initrd-setup-root-after-ignition: Use update key for initrd sysext DL #71

Merged
merged 2 commits into from
Sep 21, 2023

Conversation

pothos
Copy link
Member

@pothos pothos commented Sep 20, 2023

The OEM and "official" Flatcar systemd-sysext images have a download mechanism in the initrd. For OEM extensions this is only a fallback in case the user deleted the files because now we have all things in place for the update to ensure that OEM payloads are there. The enabling of "official" Flatcar extensions on provisioning still would primarily go through this mechanism and therefore, it should not use the image signing key but the update key to have a single way of verifying the extensions.
Switch the extension download to use the update server and the update key for verification of the payloads.

How to use

Testing done

Kola test cl.sysext.fallbackdownload still passes

pothos added a commit to flatcar/scripts that referenced this pull request Sep 20, 2023
This pulls in flatcar/bootengine#71
to switch the extension download to use the update server and the update
key for verification of the payloads.
@pothos pothos force-pushed the kai/fallback-update-key branch 2 times, most recently from 8febf6a to c598795 Compare September 20, 2023 18:30
pothos added a commit to flatcar/scripts that referenced this pull request Sep 20, 2023
This pulls in flatcar/bootengine#71
to switch the extension download to use the update server and the update
key for verification of the payloads.
@pothos pothos requested a review from a team September 21, 2023 09:35
Comment on lines +20 to +22
if [ "$(usrbin md5sum /sysroot/usr/share/update_engine/update-payload-key.pub.pem | cut -d " " -f 1)" = "7192addf4a7f890c0057d21653eff2ea" ]; then
URL="https://bincache.flatcar-linux.net/images/${FLATCAR_BOARD/-usr}/${VERSION}/flatcar_test_update-${name}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment about this magic number (a hash of some testing key?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's the dev key, done.

rm -rf "${GNUPGHOME}"
rm -f "/sysroot/${name}"
usrcurl -o "/sysroot/${name}" "${URL}" || { rm -f "/sysroot/${name}" ; return 1 ; }
PROTOPATH=/usr/share/update_engine/ usrbin unshare -m sh -c "mount --rbind /dev /sysroot/dev/ && mount -t proc /proc /sysroot/proc/ && chroot /sysroot /usr/share/update_engine/decode_payload /usr/share/update_engine/update-payload-key.pub.pem \"/${name}\" \"/${final_name}\"" || { rm -f "/sysroot/${final_name}" ; echo "Failing boot" >&2 ; exit 1; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should maybe the PROTOPATH env var be specified somewhere inside the sh -c parameter? It probably works where it is now, but it's quite far away from the actual user of the variable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

The OEM and "official" Flatcar systemd-sysext images have a download
mechanism in the initrd. For OEM extensions this is only a fallback in
case the user deleted the files because now we have all things in place
for the update to ensure that OEM payloads are there. The enabling of
"official" Flatcar extensions on provisioning still would primarily go
through this mechanism and therefore, it should not use the image
signing key but the update key to have a single way of verifying the
extensions.
Switch the extension download to use the update server and the update
key for verification of the payloads.
For the OEM extension fallback download the networking was enabled, for
the "official" Flatcar extension download not.
Enable networkd and resolved like done for the OEM extension download.
@pothos pothos merged commit 2c0968a into flatcar-master Sep 21, 2023
@pothos pothos deleted the kai/fallback-update-key branch September 21, 2023 11:59
pothos added a commit to flatcar/scripts that referenced this pull request Sep 21, 2023
This pulls in flatcar/bootengine#71
to switch the extension download to use the update server and the update
key for verification of the payloads.
pothos added a commit to flatcar/scripts that referenced this pull request Sep 21, 2023
This pulls in flatcar/bootengine#71
to switch the extension download to use the update server and the update
key for verification of the payloads.
pothos added a commit to flatcar/scripts that referenced this pull request Oct 2, 2023
This pulls in flatcar/bootengine#71
to switch the extension download to use the update server and the update
key for verification of the payloads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants