Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client: Always initialize keys DB from local storage #92

Merged
merged 1 commit into from
Feb 11, 2016

Conversation

lmars
Copy link
Contributor

@lmars lmars commented Feb 10, 2016

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

@titanous
Copy link
Contributor

Sounds good, add a test.

@vladimir-v-diaz
Copy link
Contributor

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>
@lmars
Copy link
Contributor Author

lmars commented Feb 11, 2016

@vladimir-v-diaz

It might be good to also rebuild the locally trusted keys DB once you've fully validated the new root metadata

The library already does this. If you look at Client.Update, it calls updateWithLatestRoot on various conditions (e.g. if the local metadata expired, keys have been revoked etc.) which downloads and persists the new root manifest.

@lmars
Copy link
Contributor Author

lmars commented Feb 11, 2016

@titanous test updated to cover the issue.

@titanous
Copy link
Contributor

LGTM

lmars added a commit that referenced this pull request Feb 11, 2016
client: Always initialize keys DB from local storage
@lmars lmars merged commit 6093a53 into master Feb 11, 2016
@lmars lmars deleted the fix-local-expired-root branch February 11, 2016 02:19
rdimitrov pushed a commit to rdimitrov/go-tuf that referenced this pull request Jan 25, 2024
…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>
rdimitrov pushed a commit that referenced this pull request Jan 29, 2024
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>
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.

3 participants