design spec_version updates
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
先閱讀 issue #2040，以及現有的 python-tuf 中繼資料與儲存庫更新行為。比較這裡描述的三種 spec_version 策略，包括 succinct delegations 如何影響相容性。完成的標準是記錄由誰設定版本、需要哪些工具，並確定一個用於判定最低支援 spec_version 的設計。
由索引模型根據 Issue 內容生成。
描述
Since a incompatible spec version update seems to get more interest (see #2040), we should start with actually designing how spec version numbers are going to work... Who is responsible for setting the version and what tools exist to help there?
As an example, lets say that TUF spec decides that succinct delegations are an incompatible spec addition -- this is a reasonable decision as adding succinct delegations to a targets metadata makes it invalid for older clients. Let's say, this is spec version 2.0.0.
Assume python-tuf supports spec 2.0.0. Now repositories are going to have many reasonable choices. At least these exist:
- start using 2.0.0 in all new metadata files (but keep old ones as is even when the are resigned). This is what happens by default with current python-tuf: this leads to bugs as soon as
- succinct delegations are added to existing metadata
- new metadata is added that old clients should be able to access
- start using 2.0.0 in all metadata files whenever they get re-signed. Issues appear when:
- any metadata that old clients should be able to access is resigned
- start using 2.0.0 in all metadata that contain succinct delegations but legacy version in all others, even newly created metadata -- this allows old clients to keep accessing any metadata that doesn't contain succinct delegations
The last one is arguably most useful but also quite tricky to implement, at least in python-tuf (likely a lot easier in the repository itself): it might be possible to write methods that scans the metadata structure and decides "what is the lowest spec version that this structure supports": this method could be used by the repository when it's updating expiry,version,etc metadata content to also set spec_version at that time.
- 主要語言
- Python
- 星號
- 1.7k
- 分支
- 307
- 平均合併
- 8 小時 11 分鐘
- 30 天內合併 PR
- 12
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
theupdateframework/python-tuf 的其他 Issue
-
Metadata API: SuccinctRoles.is_delegated_role() accepts non-canonical bin names可能已有人在做 @Anandb71 於 6 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 42/100
theupdateframework/python-tuf#3033 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
theupdateframework/python-tuf#3001 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 42/100
theupdateframework/python-tuf#2979 · 1 則留言 ·
維護者通常 1 天內回覆
-
enhancement github_actions
難度 3/5 1-2 天 新手友好度 45/100
theupdateframework/python-tuf#2920 · 1 則留言 · 2 個 reaction ·
維護者通常 1 天內回覆
-
Investigate/test fetcher retries可能已有人在做 @ishaanxgupta 於 291 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 35/100
theupdateframework/python-tuf#2842 · 3 則留言 ·
維護者通常 1 天內回覆
查看 theupdateframework/python-tuf 的全部 Issue
相似的 Issue
-
intake mcp-intake needs-ac needs-human-review priority:medium
難度 2/5 1-3 小時 新手友好度 67/100
Ikalus1988/MisakaNet#3848 · 2 則留言 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 75/100
521xueweihan/HelloGitHub#4105 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
igormcsouza/bookloud#54 ·
-
難度 1/5 1 小時以內 新手友好度 90/100
aws-samples/sample-per-model-bedrock#526 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
ok-oldking/ok-wuthering-waves#1802 ·
維護者通常 2 天內回覆