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

RepositorySimulator: add support for serving invalid metadata #1615

Closed
sechkova opened this issue Oct 13, 2021 · 6 comments
Closed

RepositorySimulator: add support for serving invalid metadata #1615

sechkova opened this issue Oct 13, 2021 · 6 comments
Assignees
Labels
backlog Issues to address with priority for current development goals
Milestone

Comments

@sechkova
Copy link
Contributor

sechkova commented Oct 13, 2021

Description of issue or feature request:

update: One scenario of invalid metadata remains, serving a snapshot whose version does not match the one in timestamp.snapshot_meta and targets whose version does not match the one in snapshot.meta respectively (see discussion below).

In many test scenarios there is a need of serving various forms of invalid metadata:

  • unsigned metadata: missing signatures, threshold of signatures is not met, signed with incorrect keys
  • tampered metadata: snapshot/targets hash not matching
  • expired metadata

Current behavior:
All metadata is served signed, hard to tweak signatures, hard to tweak hashes.

Expected behavior:
Add options and/or methods to RepositorySimulator facilitating serving invalid metadata.

@jku jku added the backlog Issues to address with priority for current development goals label Oct 13, 2021
@jku jku added this to the Sprint 10 milestone Oct 13, 2021
@jku
Copy link
Member

jku commented Oct 14, 2021

  • unsigned metadata: missing signatures, threshold of signatures is not met, signed with incorrect keys
  • tampered metadata: snapshot/targets hash not matching
  • expired metadata

let's talk about these: I think these are mostly already doable -- but it's true the methods to do so might not be very accessible.

  • unsigned metadata: changing signers without changing metadata keys will lead to signature issues
  • invalid metadata (meta dict): this should be easy, just modify meta dict manually after update_snapshot()
  • invalid metadata (target hashes): this might require adding the target, then modifying the metadata...
  • expired metadata: modifying expiry should be easy

@sechkova
Copy link
Contributor Author

Thanks for expanding on the bullets, I managed to apply all these successfully in #1636.

Only one issue remained, partially related to consistent snapshot. Since RepositorySimulator works always with consistent snapshot enabled this forces the client to look for the snapshot version written in timestamp, which leads to "Unknown snapshot version" when trying to serve a snapshot with a version mismatching the one in timestamp.snapshot_meta.
Here is an example:

# TODO: RepositorySimulator works always with consistent snapshot

The only idea I got is to test this when RepositorySimulator supports consistent_snapshot turned off. Any better ideas?

I plan to close this issue and open another one for implementing the above.

@jku
Copy link
Member

jku commented Oct 26, 2021

The only idea I got is to test this when RepositorySimulator supports consistent_snapshot turned off. Any better ideas?

yeah I see. The simulator does not in any way "publish" non-root metadata so when a request is made it just checks if the requested version matches current metadata...

I guess one option is to just not check for the version match in the simulator: instead always return the current metadata, whatever version is requested. I have no idea if this would complicate some other tests, but I remember originally adding the check only to test that the simulator works... maybe it isn't needed?

@sechkova
Copy link
Contributor Author

I will add these notes to #1637 to test if removing the check causes any problems with consistent/non-consistent snapshot. I did actually run my tests with commenting out the check you mention and nothing wrong happened ...

@jku
Copy link
Member

jku commented Nov 10, 2021

Is this still an issue with the changes in #1636?

@sechkova
Copy link
Contributor Author

Is this still an issue with the changes in #1636?

No, the last item from this issue was fixed with d66c3ba. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Issues to address with priority for current development goals
Projects
None yet
Development

No branches or pull requests

2 participants