mottetm

@rverma-nsl Did you ever figure out what was the root cause of your first issue? Facing the same but can't figure out what the issue is...

What about making the timeout configurable? The users know best what their use-case is and if it makes sense to time out quickly or to wait for the upstream response.

~~Kind of the opposite. In our case, the call to the upstream registry will never return. But push are still waiting for the call to complete. Which happens after sometime...

@smira would there be any chance to add a feature that would enable the user to specify a public key in the kernel arguments, and that would use that public...

Not quite. The difference is that embedding the config the "proper" way is going to modify the content of the PCRs. Which means that we would have to recompute them...

Maybe a bit of background. Our idea was to request our OEM to generate key-pairs bound to a specific PCR policy matching our generic ISO and to share with us...

Building on @stereobutter's point about scope, reusing the SecureBoot key also presents implementation challenges. Looking at the current [readConfigFromISO](https://github.com/siderolabs/talos/blob/798143a886e4055e764a9ad17cefe8ad4db0572e/internal/app/machined/pkg/runtime/v1alpha1/platform/metal/metal.go#L124), adding verification via a kernel-arg-provided public key would be straightforward using...