Skip to content

Conversation

@vladimir-v-diaz
Copy link
Contributor

@vladimir-v-diaz vladimir-v-diaz commented May 18, 2017

Clients should validate new root.json according to the threshold and keys set by its previous version.

See @heartsucker's comment here.

Client's should validate new root.json according to the threshold and keys set by its previous version.

See @heartsucker comment [here](theupdateframework/rust-tuf#42 (comment))
@vladimir-v-diaz vladimir-v-diaz requested a review from awwad May 18, 2017 15:54
@vladimir-v-diaz
Copy link
Contributor Author

vladimir-v-diaz commented May 18, 2017

@heartsucker Let us know if this PR captures the case you raised in issue rust-tuf/32

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.936% when pulling 63ec868 on vladimir-v-diaz-patch-1 into ec83e56 on develop.

Copy link
Contributor

@awwad awwad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's still a bit confusing. How about this paragraph?

	   To replace a compromised root key or any other top-level role key, the root
	   role signs a new root.json file that lists the updated trusted keys for the
	   role.
	   In the event that the keys being updated are root keys, it is important to
	   note that the new root.json must at least be signed by the keys listed as
	   root keys in the previous version of root.json, up to the threshold listed for
	   root in the previous version of root.json. If this is not the case, clients will
	   (correctly) not validate the new root.json file.

@vladimir-v-diaz
Copy link
Contributor Author

@awwad I added your and heartsucker's suggestions. What do you think of the changes?

@awwad
Copy link
Contributor

awwad commented May 18, 2017

I think it's good, with the typo at the end fixed. You don't think my wording was wordy / unclear, then, I gather?

@awwad
Copy link
Contributor

awwad commented May 18, 2017

Oh - btw, contingent on the instructions for the client updater procedure being added as well, which we talked about. (Something like what @heartsucker has in #444). I guess @trishankkarthik is doing that?

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.936% when pulling 7c96933 on vladimir-v-diaz-patch-1 into ec83e56 on develop.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.936% when pulling 7c96933 on vladimir-v-diaz-patch-1 into ec83e56 on develop.

@vladimir-v-diaz
Copy link
Contributor Author

Yup, a detailed client update workflow is being added to the specification in pull request #440.

@vladimir-v-diaz vladimir-v-diaz merged commit 70cf57a into develop May 18, 2017
@vladimir-v-diaz vladimir-v-diaz deleted the vladimir-v-diaz-patch-1 branch July 11, 2017 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants