jul-sh

Ideally the [get_attestation](https://github.com/project-oak/oak/blob/7e7ee8545ac66be77db19d769041b8b8da3b4fd6/stage0/src/dice_attestation.rs#L156) should probably return the whole relevant [root layer evidence](https://github.com/project-oak/oak/blob/7e7ee8545ac66be77db19d769041b8b8da3b4fd6/oak_dice/src/evidence.rs#L72).

I don't have a strong objection to merging this. But the rationale for the original naming choice of `attestation` that the provided crypto functions operate with keys that are specifically...

Is there any dependency of AttestationEvidence left? It was deprecated in https://github.com/project-oak/oak/pull/4489. If not we should fully remove it after this PR.

> I think this needs some synchronisation with #4655. It might be possible to directly remove the deprecated evidence after that rather than also doing this intermediate step. Okay! Will...

> Thanks Juliette! Will this change be breaking, once imported into google3, or should no one depend on those protos that were moved? It will be breaking.

> Could you do it in non-breaking steps, like #4661 ? #4661 was infact breaking. Client teams depended on it in order to build grpc clients. See http://cs/h/quirk-internal/confidential-federated-compute/+/main:third_party/oak/BUILD.containers.patch This change...

> How was that breaking? AFAICT it is only adding new protos. The idea being that clients can migrate one by one to the new protos, at which point we...

Updated to preserve the old files. As a nit, per the definition you quoted it would still be considered breaking, unless we include > I'd like us to avoid breaking...

Yup, we won't be able to fully deduplicate because of that. Also it's worth noting that stage0n depends on oak_dice, so deps should be kept limited in general.

are there plans to implement this?