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
In a serverless world, where clouds are moving to on-demand instancing of workloads, we need to account for nodes that are delivered to users on-demand.
This means the client has no historical, trusted reference point.
If we don't trust a single endpoint ( the registry) then we must account for how a client is configured quickly as clouds are striving for sub second instancing of a container on ephemeral nodes.
The text was updated successfully, but these errors were encountered:
I'd say this applies not only to clients verifying signatures, but also to ephemeral CI build nodes that are signing images. At least some users will perform the signing as part of their CI pipeline and inject a delegated signing key for the task. This would mean that no stateful data can be required on the signing node, e.g. we can't rely on the build node to know the state of all the other signatures in the repository (this could impact the options a potential TUF implementation has to managing the targets metadata).
In a serverless world, where clouds are moving to on-demand instancing of workloads, we need to account for nodes that are delivered to users on-demand.
This means the client has no historical, trusted reference point.
If we don't trust a single endpoint ( the registry) then we must account for how a client is configured quickly as clouds are striving for sub second instancing of a container on ephemeral nodes.
The text was updated successfully, but these errors were encountered: