-
Notifications
You must be signed in to change notification settings - Fork 55
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
Do we always need to download snapshot and targets? #227
Comments
Thanks for the feedback / question!
The timestamp role contains the hash, version, and size of the snapshot.
These should either all match, or all fail together if the information is
mismatched.
- When updating a delegated targets metadata, check if the delegating
targets role's version matches the trusted delegated targets version, and
has the correct hash value, if present.
The snapshot role contains the version of all of the targets metadata files
(top-level or delegated). So in this case, I think you may mean to say
snapshot file (or I am confused about what you are saying).
…On Thu, May 19, 2022 at 1:29 PM Erick Tryzelaar ***@***.***> wrote:
I'm updating rust-tuf to work with TUF-1.0.30. As part of reading through
the spec, I that @rdimitrov <https://github.com/rdimitrov> changed the
spec in #209
<#209> to allow
us to exit the update-cycle early in update-timestamp 5.4.3.1
<https://theupdateframework.github.io/specification/latest/#update-timestamp>.
Should we apply this same logic to snapshots and targets?
rust-tuf currently implements this, where it will exit early if:
- When updating the snapshot metadata, check if the trusted timestamp
role's snapshot version matches the trusted snapshot version, and has the
correct hash value, if present.
- When updating the targets metadata, check if the trusted snapshot
role's targets version matches the trusted targets version, and has the
correct hash value, if present.
- When updating a delegated targets metadata, check if the delegating
targets role's version matches the trusted delegated targets version, and
has the correct hash value, if present.
-
Is this optimization allowed? If so, should we describe it in the spec? If
not, why is this dangerous?
—
Reply to this email directly, view it on GitHub
<#227>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGROD3I2XLRZMTTKRTSKHLVKXGTZANCNFSM5WK7BZ7Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Yes, I would say this optimisation is allowed. If the metadata on-disk matches what is described (version, hashes) by the describing^ verified/trusted metadata (timestamp->snapshot, snapshot->targets), we do not need to download the metadata. python-tuf also implements these optimisations. ^ Do we have a good term for this? |
Since it’s now optional for us to have the hashes of the metadata, do you still think this optimization is safe if we don’t have hashes? The metadata signatures should still protect us from forgery. |
Oops, yeah I meant the snapshot file. |
Short answer: Yes, it is safe to only have version numbers of targets files
listed in snapshot.
Long answer:
https://www.usenix.org/system/files/conference/atc17/atc17-kuppusamy.pdf
…On Thu, May 19, 2022 at 10:05 PM Erick Tryzelaar ***@***.***> wrote:
Since it’s now optional for us to have the hashes of the metadata, do you
still think this optimization is safe if we don’t have hashes? The metadata
signatures should still protect us from forgery.
—
Reply to this email directly, view it on GitHub
<#227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGROD7HYDJP7UYBFDNR4XDVKZDDNANCNFSM5WK7BZ7Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I have wondered that too. I think I've seen "signs metadata for" in some TUF diagrams. If we find a good term, we should put it in a glossary. |
FYI I started exploring this in #226.
@joshuagl / @lukpueh - In rust-tuf, we call this |
I'm updating rust-tuf to work with TUF-1.0.30. As part of reading through the spec, I that @rdimitrov changed the spec in #209 to allow us to exit the update-cycle early in update-timestamp 5.4.3.1. Should we apply this same logic to snapshots and targets?
rust-tuf currently implements this, where it will exit early if:
Is this optimization allowed? If so, should we describe it in the spec? If not, why is this dangerous?
The text was updated successfully, but these errors were encountered: