Expiration check does not follow the spec
See original GitHub issueDescription of issue or feature request:
The metadata expiry check code does not follow the specification:
Check for a freeze attack. The expiration timestamp in the trusted $ROLE metadata file MUST be higher than the fixed update expiration time.
Current behavior:
expires < now
Expected behavior:
expires <= now
Issue Analytics
- State:
- Created 3 years ago
- Comments:22 (19 by maintainers)
Top Results From Across the Web
When Do Checks Expire? - Investopedia
Key Takeaways · By law, banks are only required to honor checks for up to six months.1 · It's wise to contact the...
Read more >specification/tuf-spec.md at master - GitHub
The framework downloads the file and performs security checks to ensure that the downloaded file is exactly what is expected according to the...
Read more >how do i test cookie expiry in rails rspec - Stack Overflow
To test that expiry is being set properly in the controller setting the cookie, you could stub out the #cookies method and make...
Read more >Product Dating Information Statement - Sigma-Aldrich
Sigma-Aldrich further suggests following industry laboratory practices of using products with no expiration date or retest dates within 5 years ...
Read more >HTTP/1.1: Header Field Definitions
If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@joshuagl - you are correct, we are using
<=
in rust-tuf and go-tuf.I’ve created a PR against python-tuf (#1235) and filed issues against the in-toto specification (in-toto/docs#42) and reference implementation (in-toto/in-toto#417). That just leaves Tough that doesn’t follow the rough consensus here, @iliana would you like me to file an issue there?