This repository was archived by the owner on May 26, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 16
This repository was archived by the owner on May 26, 2023. It is now read-only.
Signing with multiple scheme versions #85
Copy link
Copy link
Open
Labels
kind/enhancementEnhancement, improvement, extensionEnhancement, improvement, extensionlifecycle/staleNobody worked on this for 6 months (will further age)Nobody worked on this for 6 months (will further age)
Description
What would you like to be added:
The current signing solution works only with a single persistence version for the component descriptor.
But we will for sure have at least one more. All desired changes have been postponed so far and will lead to a new more
K8s like representation.
The new implementation of the component lib already introduced an internal version, which is used by the library function,
only for the external representation a dedicated schema version is generated.
Therefore we have to think about the way we handle signatures, again:
- a signature is scheme specific. In this case it would be a good idea to add the scheme a signature is intended for to the
signature/digest spec to be able to store information for multiple scheme versions. This would be useful to be able to transform the
external representation without loosing the signature. - a signature is built on the internal version, which would work if all internal versions can express the same state. If the state is
extended, a signature will again be valid only for a dedicated subset of the features of the complete descriptor. This again leads to
the necessity to add information to the signature/digest spec.
Why is this needed:
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
kind/enhancementEnhancement, improvement, extensionEnhancement, improvement, extensionlifecycle/staleNobody worked on this for 6 months (will further age)Nobody worked on this for 6 months (will further age)