Clarity needed in relation to Snapshot role and online vs offline
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation
Research direction
Compare the Snapshot key guidance in content/metadata.md and content/faq.md with the Specification cited in the issue. First establish which guidance is authoritative, then update the conflicting website wording so the references agree. Done means the FAQ and metadata documentation consistently describe Snapshot role key storage.
Written by the indexing model from the issue text.
Description
At the moment, the website can't seem to make its mind up as to whether Snapshot role keys should be online or offline.
Really someone needs to decide once and for all and stick to it, instead of all this conflicting wording.
If we consider the Specification as the ultimate source of truth, then we are told:
All keys, except those for the timestamp and mirrors roles, should be stored securely offline
content/metadata.md seems to agree:
so that the Snapshot role's keys can be kept offline, and thus more secure
So far so good. But the FAQ content/faq.md is where you have the bouncing around. On one page we are told two different things...
Three places state online:
even sharing online keys (e.g., between the Timestamp and Snapshot roles)
In contrast, the Snapshot role is updated often, signed with an online key
The Timestamp and Snapshot roles can use online keys
And then we have a suggestion of offline for Snapshot:
separate keys should be used so that the Snapshot role’s keys can be kept offline, and thus in a more secure manner.
If we assume the Specification reflects the TUF design decision, then the rest of the website should be consistent.
- Dominant language
- HTML
- Stars
- 25
- Forks
- 46
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from theupdateframework/theupdateframework.io
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
theupdateframework/theupdateframework.io#184 · 1 comment ·
-
Spec version list on the Specification page is missing v1.0.34, v1.0.35, and v1.0.36May be free again A pull request for this issue was closed without being merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 84/100
theupdateframework/theupdateframework.io#183 · 3 comments ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
theupdateframework/theupdateframework.io#182 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Broken-looking link previews on News and Adoptions pages (og:description)May be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
All issues in theupdateframework/theupdateframework.io
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 90/100
FootprintAI/Containarium#2338 ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 76/100
EchoTools/nevr-runtime#110 ·
Maintainers usually reply within 1 day
-
needs-human needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
gke-labs/kube-agents#2400 · 1 comment ·
Maintainers usually reply within 1 day
-
Device Details tables: FS/SF columns contradict each other (nfet_01v8 Vt row, pfet_01v8 Idsat row)Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
google/skywater-pdk#450 ·
-
cli documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
funnyboy-roks/inq#52 ·