Elgato_dark/python-tuf
1
0
Fork 0
mirror of https://github.com/theupdateframework/python-tuf synced 2026-05-24 10:08:28 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'develop' into _type_role_lowercase

Browse source
This commit is contained in:
Vladimir Diaz 2017-07-12 15:13:17 -04:00 committed by GitHub
commit 2b5faf4a67
1 changed files with 45 additions and 41 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

86
docs/tuf-spec.txt
View file

@ -949,14 +949,11 @@ Version 1.0 (Draft)
5.1. The client application
0. **Load the previous root metadata file.** We assume that a good, trusted
0. **Load the trusted root metadata file.** We assume that a good, trusted
copy of this file was shipped with the package manager / software updater
using an out-of-band process.
0.1. **Check signatures.** The previous root metadata file MUST have been
signed by a threshold of keys specified in the previous root metadata file.
0.2. Note that the expiration of the previous root metadata file does not
0.1. Note that the expiration of the trusted root metadata file does not
matter, because we will attempt to update it in the next step.
1. **Update the root metadata file.** Since it may now be signed using
@ -965,7 +962,7 @@ Version 1.0 (Draft)
do so, the client MUST download intermediate root metadata files, until the
latest available one is reached.
1.1. Let N denote the version number of the previous root metadata file.
1.1. Let N denote the version number of the trusted root metadata file.
1.2. **Try downloading version N+1 of the root metadata file**, up to some
X number of bytes (because the size is unknown). The value for X is set by
@ -975,27 +972,28 @@ Version 1.0 (Draft)
available, then go to step 1.8.
1.3. **Check signatures.** Version N+1 of the root metadata file MUST have
been signed by: (1) a threshold of keys specified in the previous root
been signed by: (1) a threshold of keys specified in the trusted root
metadata file (version N), and (2) a threshold of keys specified in the
current root metadata file (version N+1).
new root metadata file being validated (version N+1).
1.4. **Check for a rollback attack.** The version number of the previous
root metadata file must be less than or equal to the version number of this
root metadata file. Effectively, this means checking that the version
number signed in the current root metadata file is indeed N+1.
1.4. **Check for a rollback attack.** The version number of the trusted
root metadata file (version N) must be less than or equal to the version
number of the new root metadata file (version N+1). Effectively, this means
checking that the version number signed in the new root metadata file is
indeed N+1.
1.5. Note that the expiration of the current (intermediate) root metadata
1.5. Note that the expiration of the new (intermediate) root metadata
file does not matter yet, because we will check for it in step 1.8.
1.6. Set the previous to the current root metadata file.
1.6. Set the trusted root metadata file to the new root metadata file.
1.7. Repeat steps 1.1 to 1.7.
1.8. **Check for a freeze attack.** The latest known time should be lower
than the expiration timestamp in the current root metadata file.
than the expiration timestamp in the trusted root metadata file.
1.9. **If the the timestamp and / or snapshot keys have been rotated, then
delete the previous timestamp and snapshot metadata files.** This is done
1.9. **If the timestamp and / or snapshot keys have been rotated, then
delete the trusted timestamp and snapshot metadata files.** This is done
in order to recover from fast-forward attacks after the repository has been
compromised and recovered. A _fast-forward attack_ happens when attackers
arbitrarily increase the version numbers of: (1) the timestamp metadata,
@ -1011,15 +1009,17 @@ Version 1.0 (Draft)
filename used to download the timestamp metadata file is of the fixed form
FILENAME.EXT (e.g., timestamp.json).
2.1. **Check signatures.** The timestamp metadata file must have been
signed by a threshold of keys specified in the root metadata file.
2.1. **Check signatures.** The new timestamp metadata file must have been
signed by a threshold of keys specified in the trusted root metadata file.
2.2. **Check for a rollback attack.** The version number of the previous
2.2. **Check for a rollback attack.** The version number of the trusted
timestamp metadata file, if any, must be less than or equal to the version
number of this timestamp metadata file.
number of the new timestamp metadata file.
2.3. **Check for a freeze attack.** The latest known time should be lower
than the expiration timestamp in this metadata file.
than the expiration timestamp in the new timestamp metadata file. If so,
the new timestamp metadata file becomes the trusted timestamp
metadata file.
3. **Download and check the snapshot metadata file**, up to the number of
bytes specified in the timestamp metadata file.
@ -1032,31 +1032,34 @@ Version 1.0 (Draft)
the client MUST write the file to non-volatile storage as
FILENAME.EXT.
3.1. **Check against timestamp metadata.** The hashes, and version number
of this metadata file MUST match the timestamp metadata.
3.1. **Check against timestamp metadata.** The hashes and version number
of the new snapshot metadata file MUST match the hashes and version number
listed in timestamp metadata.
3.2. **Check signatures.** The snapshot metadata file MUST have been signed
by a threshold of keys specified in the previous root metadata file.
by a threshold of keys specified in the trusted root metadata file.
3.3. **Check for a rollback attack.**
3.3.1. Note that the previous snapshot metadata file may be checked for
3.3.1. Note that the trusted snapshot metadata file may be checked for
authenticity, but its expiration does not matter for the following
purposes.
3.3.2. The version number of the previous snapshot metadata file, if any,
MUST be less than or equal to the version number of this snapshot metadata
file.
3.3.2. The version number of the trusted snapshot metadata file, if any,
MUST be less than or equal to the version number of the new snapshot
metadata file.
3.3.3. The version number of the targets metadata file, and all delegated
targets metadata files (if any), in the previous snapshot metadata file, if
any, MUST be less than or equal to its version number in this snapshot
targets metadata files (if any), in the trusted snapshot metadata file, if
any, MUST be less than or equal to its version number in the new snapshot
metadata file. Furthermore, any targets metadata filename that was listed
in the previous snapshot metadata file, if any, MUST continue to be listed
in this snapshot metadata file.
in the trusted snapshot metadata file, if any, MUST continue to be listed
in the new snapshot metadata file.
3.4. **Check for a freeze attack.** The latest known time should be lower
than the expiration timestamp in this metadata file.
than the expiration timestamp in the new snapshot metadata file. If so,
the new snapshot metadata file becomes the trusted snapshot metadata
file.
4. **Download and check the top-level targets metadata file**, up to either
the number of bytes specified in the snapshot metadata file, or some
@ -1072,20 +1075,21 @@ Version 1.0 (Draft)
FILENAME.EXT.
4.1. **Check against snapshot metadata.** The hashes (if any), and version
number of this metadata file MUST match the snapshot metadata. This is
done, in part, to prevent a mix-and-match attack by man-in-the-middle
number of the new targets metadata file MUST match the trusted snapshot metadata.
This is done, in part, to prevent a mix-and-match attack by man-in-the-middle
attackers.
4.2. **Check for an arbitrary software attack.** This metadata file MUST
have been signed by a threshold of keys specified in the latest root
4.2. **Check for an arbitrary software attack.** The new targets metadata file
MUST have been signed by a threshold of keys specified in the trusted root
metadata file.
4.3. **Check for a rollback attack.** The version number of the previous
4.3. **Check for a rollback attack.** The version number of the trusted
targets metadata file, if any, MUST be less than or equal to the version
number of this targets metadata file.
number of the new targets metadata file.
4.4. **Check for a freeze attack.** The latest known time should be lower
than the expiration timestamp in this metadata file.
than the expiration timestamp in the new targets metadata file. If so,
the new targets metadata file becomes the trusted targets metadata file.
4.5. **Perform a preorder depth-first search for metadata about the desired
target, beginning with the top-level targets role.**