client: Always initialize keys DB from local storage#92
Conversation
|
Sounds good, add a test. |
|
It might be good to also rebuild the locally trusted keys DB once you've fully validated the new root metadata. When keys are revoked or compromised, root is updated to longer trust these keys, but subsequent root metadata may continue to provide signatures generated by these revoked keys to allow outdated clients to update. Once outdated clients download the new root, they no longer trust keys that have been revoked. You might already be doing so, but I wanted to mention it just in case. I wonder if the TUF specification is unclear on how to set the initial trust on the root keys and how they are updated when a key is revoked or compromised. While working on the PyPI+TUF proposal, the Python reviewers were unaware of this update procedure. After realizing the misunderstanding, we updated the Python proposal to say: Package managers like pip need to ship a file named "root.json" with the installation files that users initially download. This file includes information about the keys trusted for certain roles, as well as the root keys themselves. Any new version of "root.json" that clients may download are verified against the root keys that client's initially trust. If a root key is compromised, but a threshold of keys are still secured, the PyPI administrator MUST push a new release that revokes trust in the compromised keys. If a threshold of root keys are compromised, then "root.json" should be updated out-of-band, however the threshold should be chosen so that this is extremely unlikely. The TUF client library does not require manual intervention if root keys are revoked or added: the update process handles the cases where "root.json" has changed. |
If the local root is expired, an update will download the latest root from remote storage, and we need to be able to verify that new root with the local keys. Signed-off-by: Lewis Marshall <lewis@lmars.net>
c369765 to
ada2115
Compare
The library already does this. If you look at Client.Update, it calls |
|
@titanous test updated to cover the issue. |
|
LGTM |
client: Always initialize keys DB from local storage
…eframework#92) Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.16.0 to 0.17.0. - [Commits](golang/crypto@v0.16.0...v0.17.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.16.0 to 0.17.0. - [Commits](golang/crypto@v0.16.0...v0.17.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
If the local root is expired, an update will download the latest root from remote storage, and we need to be able to verify that new root with the local keys.
We should probably add a test to stop this regressing, but PRing without a test for feedback.
/cc @titanous