Repository navigation
Do we always need to download snapshot and targets? #227
Description
Activity
- 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.
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).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: ***@***.***>
... describing^ ... metadata (timestamp->snapshot, snapshot->targets) ...
^ Do we have a good term for this?
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.
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.
@joshuagl / @lukpueh - In rust-tuf, we call this
MetadataDescription, but it always felt a little awkward. Maybe "Descriptor", although that also seems a little vague.Reacted by Lukas Pühringer
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?