You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FCOS Cincinnati service receives its update metadata as JSON from the Cloudfront'ed S3 bucket over TLS. Matching the security model employed for the OSTree data itself, it'd be nice if we additionally signed this metadata and added "downgrade protection" (i.e. have the service ignore signed metadata with a metadata["last-modified"] date older than its previous fetch; though this will cause "stop this rollout" events to no longer be a pure git revert).
Also as part of this I realized that I think just due to pure oversight, rpm-ostree has never added the ostree ref binding metadata. We could consider turning that on, but we'd need to work through the implications.
Another thing that would likely help is to add a much weaker binding like ostree.binding = "coreos" and libostree would require that that metadata stay the same across upgrades by default. That would block things like a MITM offering a signed silverblue commit as an FCOS update.
Describe the enhancement
The FCOS Cincinnati service receives its update metadata as JSON from the Cloudfront'ed S3 bucket over TLS. Matching the security model employed for the OSTree data itself, it'd be nice if we additionally signed this metadata and added "downgrade protection" (i.e. have the service ignore signed metadata with a
metadata["last-modified"]
date older than its previous fetch; though this will cause "stop this rollout" events to no longer be a puregit revert
).Additional information
Came out of discussions in coreos/rpm-ostree#2819 and #749.
The text was updated successfully, but these errors were encountered: