Only define THRESHOLD once (#322)

* Only define THRESHOLD once

GH-314 introduced a second definition of THRESHOLD _without_ a <dfn> tag.

There are two ways we can fix this:
1. introduce a second dfn tag and use a for attribute on each definition,
  i.e., <dfn for="root">
2. streamline to a single definition and update the DELEGATIONS definition
  to reference the THRESHOLD definition in the root section

I've opted for 2 here as it's simpler and avoids redundant duplicate
definitions.

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

* Fix warnings from latest bikeshed

We have two definitions of KEYID and, by default, we get a random one at
build time if the `for` attribute is not specified on the anchor (<a>)
element. Squash randomness by always referring to the KEYID definition
for the root role.

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

* Pin the bikeshed version we use in workflows

This will prevent bikeshed releases unintentionally breaking our builds
without anyone noticing until a CI workflow with additional changes is
run.

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

* Update Joshua's affiliation

Changed role, updating affiliation

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

* Bump Version and Date for this PR

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

---------

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

Update canonical JSON URL in tuf-spec.md (#320)

* Update canonical JSON URL in tuf-spec.md

Updated the URL for the canonical JSON reference to an archived version since the main link is broken.

Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Apply suggestion from @JustinCappos

Date update needed to have linter / sanity checker work.

Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Apply suggestion from @JustinCappos

making the linter happy

Signed-off-by: Justin Cappos <justincappos@gmail.com>

---------

Signed-off-by: Justin Cappos <justincappos@gmail.com>

Update TUF threshold information and editor details (#314)

* Update TUF threshold information and editor details

I'm proposing a patch spec update to make it clearer that a threshold of 0 (or less) is not allowed.  See: GHSA-fphv-w9fq-2525 for more details.

I've also updated people's affiliation and suggested that slack is the best way to contact us.

Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Update tuf-spec.md

Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>
Signed-off-by: Justin Cappos <justincappos@gmail.com>

* Demote THRESHOLD "definition tag" in tuf-spec.md to fix lint

Signed-off-by: Justin Cappos <justincappos@gmail.com>

---------

Signed-off-by: Justin Cappos <justincappos@gmail.com>
Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>

Add more text describing threshold computation (#154)

* Add signature threshold computation advice

Several implementations have made similar errors -- counting multiple
signatures by the same keyid -- when implementing signature threshold
computation, for example the reference implementation:
GHSA-pwqf-9h7j-7mv8
theupdateframework/python-tuf@83ac7be

Add some extra description to the detailed client workflow to further
explain that a threshold of signatures should only count one signature
per key.

Signed-off-by: Joshua Lock <jlock@vmware.com>

* Recommend signatures only contain one sig per keyid

In an attempt to help implementers protect against incorrect threshold
computation, update "File formats" to suggest that the signatures list
contain only a single signature per keyid at metadata creation time.

Suggested-by: Jussi Kukkonen <jkukkonen@vmware.com>
Signed-off-by: Joshua Lock <jlock@vmware.com>

* Address review comments

Be more explicit that each KEYID can only count one signature towards the
threshold.

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

* Bump version and date

Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

---------

Signed-off-by: Joshua Lock <jlock@vmware.com>
Signed-off-by: Joshua Lock <joshuagloe@gmail.com>

Fix specification builds (#281)

Since the last release the GitHub Actions environment has changed such
that we now must explicitly grant permissions to actions in order to
make a release.

Signed-off-by: Joshua Lock <joshua.lock@uk.verizon.com>

Clone repository before setting up Python (#250)

Since 70f167f the setup-python action restores a cache based on the
fingerprint of requirements.txt, therefore we must ensure a copy of that
file exists before we setup Python. This order of events requires the first
action to be checkout to clone the repository.

Signed-off-by: Joshua Lock <jlock@vmware.com>

Signed-off-by: Joshua Lock <jlock@vmware.com>

Update metadata version comparison rules in client workflow (#209)

* Update metadata version comparison rules in client workflow

The client workflow has a set of version comparison rules for how
to update metadata files. The following PR addresses the differences
coming from the fact that when updating not all metadata files should
be treated equally.

Fixes #207 and is related to #114

Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com>

* Bump date and version to 1.0.29

Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com>

* Address what happens in case of equal metadata versions for client update

Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com>

* Update VERSION and Date

Co-authored-by: Joshua Lock <jlock@vmware.com>

Updated tuf-spec.md (#218)

* Updated tuf-spec.md

Added the full-form for the PKI acronym.

* Update tuf-spec.md

* Update tuf-spec.md

Remove ambiguity in update root after a failed attempt (#196)

In section 5.3. Update the root role the specification suggests, in
multiple steps (5.3.4, 5.3.5 and 5.3.10) that should the client fail to
verify the updated root metadata the downloaded data should be discarded,
the error reported, and:
> On the next update cycle, begin at step § 5.3 Update the root role and
> version N of the root metadata file.

This directive only makes sense if the client application continues
running between update cycles and therefore still has initial trusted root
metadata loaded and a fixed update start time recorded.
For at least python-tuf and go-tuf this is not how the update workflow is
implementated.

Avoid confusion by removing the recommendation to start at 5.3 on the next
update cycle and instead leave only the suggestion to remove unverified
data. Logically, the next update cycle starts at the first step -- loading
the initial trusted root metadata.

Signed-off-by: Joshua Lock <jlock@vmware.com>

A round of clean-up/clarifications (#195)

* Capitalise TAP consistently
* Clarify that mirrors are optional
* Bump Date and VERSION after edits
* Apply suggestions from code review
* Note consistent snapshot requirements in "3.1. Repository layout"
  Briefly describe the requirement for unique identification of files for
  consistent snapshots and cross-link to "6.2. Consistent snapshots" for
  more information.

Signed-off-by: Joshua Lock <jlock@vmware.com>
Co-authored-by: lukpueh <luk.puehringer@gmail.com>