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
There are a number of methods which may require breaking API changes to support delegations. These include:
Repo.GetThreshold
Repo.SetThreshold
Repo.RevokeKeyWithExpires and caller Repo.RevokeKey
Repo.AddVerificationKeyWithExpiration and all callers, including Repo.GenKey, Repo.GenKeyWithExpires, Repo.AddPrivateKey, Repo.AddPrivateKeyWithExpires, and Repo.AddVerificationKey
These APIs might need to change change to support delegations, since they implement key management for roles. However, delegated targets keys are associated with delegations, not roles (see theupdateframework/specification#214).
One option to avoid a breaking change or adding more complex APIs would be to implement them such that the key changes apply simultaneously to all incoming delegations to a given role. In most cases (except for non-tree delegation graphs such as those illustrated in theupdateframework/specification#177), there will be only one incoming delegation to a given role, so this would be intuitive behavior.
The text was updated successfully, but these errors were encountered:
These APIs might need to change change to support delegations, since they implement key management for roles. However, delegated targets keys are associated with delegations, not roles (see theupdateframework/specification#214).
Might be misinterpreting, but for GetThreshold and SetThreshold, why would the API need to change? For a delegation name, we can do a delegation search to find the delegatee role and modify the threshold thru the DelegatedRole
I think what you're describing is the same as this suggestion above:
One option to avoid a breaking change or adding more complex APIs would be to implement them such that the key changes apply simultaneously to all incoming delegations to a given role.
What I'm unsure of is whether it makes sense from a user's perspective to update the threshold for all incoming DelegatedRoles, if there are multiple delegatees.
What I'm unsure of is whether it makes sense from a user's perspective to update the threshold for all incoming DelegatedRoles, if there are multiple delegatees.
I don't think so. Some delegated roles will have different number of signers too -- however, I think in case it is easy, I think some library method should expose pulling a list of delegatees out of a delegated target file. So a user could iterate over them and set all incoming thresholds uniformly.
There are a number of methods which may require breaking API changes to support delegations. These include:
Repo.GetThreshold
Repo.SetThreshold
Repo.RevokeKeyWithExpires
and callerRepo.RevokeKey
Repo.AddVerificationKeyWithExpiration
and all callers, includingRepo.GenKey
,Repo.GenKeyWithExpires
,Repo.AddPrivateKey
,Repo.AddPrivateKeyWithExpires
, andRepo.AddVerificationKey
These APIs might need to change change to support delegations, since they implement key management for roles. However, delegated targets keys are associated with delegations, not roles (see theupdateframework/specification#214).
One option to avoid a breaking change or adding more complex APIs would be to implement them such that the key changes apply simultaneously to all incoming delegations to a given role. In most cases (except for non-tree delegation graphs such as those illustrated in theupdateframework/specification#177), there will be only one incoming delegation to a given role, so this would be intuitive behavior.
The text was updated successfully, but these errors were encountered: