@@ -40,9 +40,9 @@ Specifies the other top-level roles. When specifying these roles, the trusted
40
40
keys for each are listed, along with the minimum number of those keys required
41
41
to sign the role's metadata. We call this number the signature threshold.
42
42
43
- See an ** example **
44
-
45
- ```
43
+ < details >
44
+ < summary >< strong >Example Root metadata</ strong ></ summary >
45
+ < pre >< code >
46
46
{
47
47
"signatures": [
48
48
{
@@ -150,7 +150,8 @@ See an **example**
150
150
"version": 1
151
151
}
152
152
}
153
- ```
153
+ </code ></pre >
154
+ </details >
154
155
155
156
## Targets Metadata (targets.json)
156
157
@@ -167,8 +168,9 @@ so in a way similar to how the Root role specifies the top-level roles: by givin
167
168
the trusted keys and signature threshold for each role. Additionally, one or more
168
169
[ glob patterns] ( https://en.wikipedia.org/wiki/Glob_(programming) ) will be specified to indicate the target file paths for which clients should trust each delegated role.
169
170
170
- See as an ** example**
171
- ```
171
+ <details >
172
+ <summary ><strong >Example Targets metadata</strong ></summary >
173
+ <pre ><code >
172
174
{
173
175
"signatures": [
174
176
{
@@ -236,7 +238,8 @@ See as an **example**
236
238
"version": 1
237
239
}
238
240
}
239
- ```
241
+ </code ></pre >
242
+ </details >
240
243
241
244
## Delegated Targets Metadata (role1.json)
242
245
@@ -260,8 +263,9 @@ metadata file would be found at:
260
263
261
264
/ANOTHER_ROLE.json
262
265
263
- See ** example** of delegated Targets metadata
264
- ```
266
+ <details >
267
+ <summary ><strong >Example delegated Targets metadata</strong ></summary >
268
+ <pre ><code >
265
269
{
266
270
"signatures": [
267
271
{
@@ -317,10 +321,12 @@ See **example** of delegated Targets metadata
317
321
"version": 1
318
322
}
319
323
}
320
- ```
321
-
322
- and ** example** of a nested delegation
323
- ```
324
+ </code ></pre >
325
+ </details >
326
+ and
327
+ <details >
328
+ <summary ><strong >Example nested delegation</strong ></summary >
329
+ <pre ><code >
324
330
{
325
331
"signatures": [
326
332
{
@@ -338,7 +344,8 @@ and **example** of a nested delegation
338
344
"version": 1
339
345
}
340
346
}
341
- ```
347
+ </code ></pre >
348
+ </details >
342
349
343
350
## Snapshot Metadata (snapshot.json)
344
351
@@ -350,8 +357,9 @@ view of all files on the repository. That is, metadata files (and thus Target
350
357
files) that existed on the repository at different times cannot be combined
351
358
and presented to clients by an attacker.
352
359
353
- See ** example** of Snapshot metadata.
354
- ```
360
+ <details >
361
+ <summary ><strong >Example Snapshot metadata</strong ></summary >
362
+ <pre ><code >
355
363
{
356
364
"signatures": [
357
365
{
@@ -379,7 +387,8 @@ and presented to clients by an attacker.
379
387
"version": 1
380
388
}
381
389
}
382
- ```
390
+ </code ></pre >
391
+ </details >
383
392
384
393
## Timestamp Metadata (timestamp.json)
385
394
@@ -403,8 +412,9 @@ keys should be used for signing the snapshot.json file so that the
403
412
Snapshot role's keys can be kept offline, and thus more secure.
404
413
* Timestamp.json may be given to mirrors.
405
414
406
- See ** example** of Timestamp metadata.
407
- ```
415
+ <details >
416
+ <summary ><strong >Example Timestamp metadata</strong ></summary >
417
+ <pre ><code >
408
418
{
409
419
"signatures": [
410
420
{
@@ -430,4 +440,5 @@ See **example** of Timestamp metadata.
430
440
"version": 1
431
441
}
432
442
}
433
- ```
443
+ </code ></pre >
444
+ </details >
0 commit comments