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
New repository tools should provide option to write consistent snapshots #151
Most likely. I thought about it some more and concluded it supports a lot of the "hashalg.hash.filename" behavior I imagined (e.g., change the hash alg and not require a single change to parsing code). It's nice and simple.
Most likely. I thought about it some more and concluded it supports a lot
of the "hashalg.hash.filename" behavior I imagined (e.g., change the hash
alg and not require a single change to parsing code). It's nice and simple.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/151#issuecomment-32274157
.
Support multiple hash algorithms, where the generated digests of metadata and target files is included in metadata (and filenames if 'consistent_snapshots' is True). Previously, only a single hash algorithm was supported, and it was set by default to 'sha256' in code. Repository maintainers may now choose any, and/or multiple, hash algorithms from those supported by TUF. By default, 'sha256' is used when generating digests.
Support the recent change to the TUF specification, where writing consistent snapshots may include N versions of identical metadata and targets, if N hash algorithms is used by the repository when generating metadata.
Update code affected by the recent changes to the specification, such as targets that may include digests in their filename.
Support consistent snapshots of compressed metadata, including repositories that provide multiple versions of metadata with different digests included in filenames.
The repository tools can now load repositories that include consistent snapshots of metadata and targets, including those with multiple (i.e., multiple digests prepended to filenames) consistent snapshots of files.
The client code (i.e., updater.py and interposition) may now read repositories with 'consistent_snapshots': true in Root metadata, and properly request and update files with digests included.
Summary of previous implementation updates:
Update Root schema
Support writing metadata in rolename.ext and digest.rolename.ext formats.
Modify libtuf.py methods that walk and extract metadata to recognize the digest.rolename.ext format.
Write root.txt and timestamp.txt if consistent_snapshots is True.
Support automatic version increments of delegated metadata.
Still need to update logger messages (not obvious that compressed and uncompressed hashes are verified), documentation, minor issues, and refactor a few things.
Activity
Initial implementation of Issue #151.
vladimir-v-diaz commentedon Jan 14, 2014
Writing consistent snapshots:
JustinCappos commentedon Jan 14, 2014
Cool. So we decided to ditch the hashalg.hash.filename format?
Justin
On Tue, Jan 14, 2014 at 10:10 AM, Vladimir Diaz notifications@github.comwrote:
vladimir-v-diaz commentedon Jan 14, 2014
Most likely. I thought about it some more and concluded it supports a lot of the "hashalg.hash.filename" behavior I imagined (e.g., change the hash alg and not require a single change to parsing code). It's nice and simple.
JustinCappos commentedon Jan 14, 2014
Okay, how does this work? What is the rationale?
Justin
On Tue, Jan 14, 2014 at 10:31 AM, Vladimir Diaz notifications@github.comwrote:
Finish initial implementation of Issue #151 and reading consistent sn…
vladimir-v-diaz commentedon Jan 17, 2014
Support multiple hash algorithms, where the generated digests of metadata and target files is included in metadata (and filenames if 'consistent_snapshots' is True). Previously, only a single hash algorithm was supported, and it was set by default to 'sha256' in code. Repository maintainers may now choose any, and/or multiple, hash algorithms from those supported by TUF. By default, 'sha256' is used when generating digests.
Support the recent change to the TUF specification, where writing consistent snapshots may include N versions of identical metadata and targets, if N hash algorithms is used by the repository when generating metadata.
Update code affected by the recent changes to the specification, such as targets that may include digests in their filename.
Support consistent snapshots of compressed metadata, including repositories that provide multiple versions of metadata with different digests included in filenames.
The repository tools can now load repositories that include consistent snapshots of metadata and targets, including those with multiple (i.e., multiple digests prepended to filenames) consistent snapshots of files.
The client code (i.e., updater.py and interposition) may now read repositories with 'consistent_snapshots': true in Root metadata, and properly request and update files with digests included.
Summary of previous implementation updates:
Update Root schema
Support writing metadata in rolename.ext and digest.rolename.ext formats.
Modify libtuf.py methods that walk and extract metadata to recognize the digest.rolename.ext format.
Write root.txt and timestamp.txt if consistent_snapshots is True.
Support automatic version increments of delegated metadata.
vladimir-v-diaz commentedon Jan 17, 2014
Writing consistent snapshots, where metadata and target files may include the digests generated by multiple hash algorithms:
vladimir-v-diaz commentedon Jan 17, 2014
Observed:
vladimir-v-diaz commentedon Jan 17, 2014
Logger output when 'consistent_snapshots' is True:
trishankkarthik commentedon Jan 17, 2014
Great! Could you test this on a target in a delegated targets role,
just to be sure?
vladimir-v-diaz commentedon Jan 17, 2014
Good idea. I had not tested delegated roles until you mentioned it.
Observed:
vladimir-v-diaz commentedon Jan 17, 2014
Still need to update logger messages (not obvious that compressed and uncompressed hashes are verified), documentation, minor issues, and refactor a few things.
trishankkarthik commentedon Jan 17, 2014
On 01/17/2014 11:55 AM, Vladimir Diaz wrote:
Very good, thanks! Looks like everything works as it should.
Address Issues #151 and #156.
vladimir-v-diaz commentedon Jan 19, 2014
Verifying compressed and uncompressed metadata:
trishankkarthik commentedon Jan 19, 2014
Why is the second log entry a warning, when expected == observed?
On Sat, Jan 18, 2014 at 8:46 PM, Vladimir Diaz notifications@github.comwrote:
Update issues #151 and #137.
vladimir-v-diaz commentedon Jan 21, 2014
Update docstrings and comments and complete the initial implementation of issue 151.
Adjust logger level for tuf.download._check_downloaded_length().