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
{{ message }}
Repository navigation
RepositorySimulator: add support for serving invalid metadata #1615
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.
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:
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?
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 ...
Activity
jku commentedon Oct 14, 2021
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.
sechkova commentedon Oct 26, 2021
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
RepositorySimulatorworks 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 intimestamp.snapshot_meta.Here is an example:
python-tuf/tests/test_updater_top_level_update.py
Line 280 in 6565365
The only idea I got is to test this when
RepositorySimulatorsupports consistent_snapshot turned off. Any better ideas?I plan to close this issue and open another one for implementing the above.
jku commentedon Oct 26, 2021
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 commentedon Oct 26, 2021
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 commentedon Nov 10, 2021
Is this still an issue with the changes in #1636?
sechkova commentedon Nov 10, 2021
No, the last item from this issue was fixed with d66c3ba. Closing.