3636 Key ,
3737 Metadata ,
3838 MetaFile ,
39- Role ,
4039 Root ,
4140 Snapshot ,
4241 TargetFile ,
@@ -96,12 +95,7 @@ def _in(days: float) -> datetime:
9695# The targets role guarantees integrity for the files that TUF aims to protect,
9796# i.e. target files. It does so by listing the relevant target files, along
9897# with their hash and length.
99- roles ["targets" ] = Metadata [Targets ](
100- signed = Targets (
101- version = 1 , spec_version = SPEC_VERSION , expires = _in (7 ), targets = {}
102- ),
103- signatures = {},
104- )
98+ roles ["targets" ] = Metadata (Targets (expires = _in (7 )))
10599
106100# For the purpose of this example we use the top-level targets role to protect
107101# the integrity of this very example script. The metadata entry contains the
@@ -124,15 +118,7 @@ def _in(days: float) -> datetime:
124118# by listing all available targets metadata files at their latest version. This
125119# becomes relevant, when there are multiple targets metadata files in a
126120# repository and we want to protect the client against mix-and-match attacks.
127- roles ["snapshot" ] = Metadata [Snapshot ](
128- Snapshot (
129- version = 1 ,
130- spec_version = SPEC_VERSION ,
131- expires = _in (7 ),
132- meta = {"targets.json" : MetaFile (version = 1 )},
133- ),
134- {},
135- )
121+ roles ["snapshot" ] = Metadata (Snapshot (expires = _in (7 )))
136122
137123# Timestamp (freshness)
138124# ---------------------
@@ -146,15 +132,7 @@ def _in(days: float) -> datetime:
146132# format. But given that timestamp metadata always has only one entry in its
147133# 'meta' field, i.e. for the latest snapshot file, the timestamp object
148134# provides the shortcut 'snapshot_meta'.
149- roles ["timestamp" ] = Metadata [Timestamp ](
150- Timestamp (
151- version = 1 ,
152- spec_version = SPEC_VERSION ,
153- expires = _in (1 ),
154- snapshot_meta = MetaFile (version = 1 ),
155- ),
156- {},
157- )
135+ roles ["timestamp" ] = Metadata (Timestamp (expires = _in (1 )))
158136
159137# Root (root of trust)
160138# --------------------
@@ -168,32 +146,19 @@ def _in(days: float) -> datetime:
168146# 'keys' field), and a configuration parameter that describes whether a
169147# repository uses consistent snapshots (see section 'Persist metadata' below
170148# for more details).
171- #
149+
150+ # Create root metadata object
151+ roles ["root" ] = Metadata (Root (expires = _in (365 )))
152+
172153# For this example, we generate one 'ed25519' key pair for each top-level role
173154# using python-tuf's in-house crypto library.
174155# See https://github.com/secure-systems-lab/securesystemslib for more details
175156# about key handling, and don't forget to password-encrypt your private keys!
176157for name in ["targets" , "snapshot" , "timestamp" , "root" ]:
177158 keys [name ] = generate_ed25519_key ()
178-
179- # Create root metadata object
180- roles ["root" ] = Metadata [Root ](
181- signed = Root (
182- version = 1 ,
183- spec_version = SPEC_VERSION ,
184- expires = _in (365 ),
185- keys = {
186- key ["keyid" ]: Key .from_securesystemslib_key (key )
187- for key in keys .values ()
188- },
189- roles = {
190- role : Role ([key ["keyid" ]], threshold = 1 )
191- for role , key in keys .items ()
192- },
193- consistent_snapshot = True ,
194- ),
195- signatures = {},
196- )
159+ roles ["root" ].signed .add_key (
160+ name , Key .from_securesystemslib_key (keys [name ])
161+ )
197162
198163# NOTE: We only need the public part to populate root, so it is possible to use
199164# out-of-band mechanisms to generate key pairs and only expose the public part
0 commit comments