Should POUF-1 allow whitespace for prettified output?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- json
- Domain
- documentation
Research direction
Start by reading the POUF-1 reference specification and OLPC's Canonical JSON definition linked in the issue, then review the rust-tuf JsonPretty implementation for the contrasting behavior. Done means deciding whether whitespace-prettified POUF-1 is formally supported and documenting how implementations should classify or refer to it.
Written by the indexing model from the issue text.
Description
In this conversation on #tuf, I'm in the process of renaming rust-tuf's interchange types to pouf, since that's more aligned with the tuf project. One complication though is that rust-tuf supports a prettified version of pouf-1 with JsonPretty. We use this to generate golden files to make sure code changes don't unintentionally change pregenerated metadata. It's much easier to read pretty json than minified json. However, according to pouf-1, this format uses OLPC's canonical json format, which disallows whitespace.
rust-tuf, and I'm guessing all the other implementations of POUF-1, can work with prettified metadata without issue. Should this be something that's formally supported? Or should implementations like this be treated as a non-standard POUF? If the latter, how should we refer to things like this? Should we avoid using the term POUF with things like this?
- Dominant language
- No language data
- Stars
- 37
- Forks
- 23
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
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/taps
-
Difficulty 5/5 Over a week Newbie friendliness 42/100
theupdateframework/taps#194 ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
theupdateframework/taps#191 · 8 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
theupdateframework/taps#190 · 19 comments · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 32/100
theupdateframework/taps#178 · 1 comment · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
theupdateframework/taps#177 · 1 comment · 3 reactions ·
All issues in theupdateframework/taps
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Ecosystem: ClawMetry — the Qwen Code reader is now free and open source (follow-up to #9294 / #9338) Opencategory/integration priority/P3 scope/documentation status/ready-for-human type/feature-request
Difficulty 1/5 Under an hour Newbie friendliness 84/100