Must signed.version be incremented every time a role is re-signed?
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tài liệu
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- documentation, security
Hướng nghiên cứu
Bắt đầu với phần định dạng tệp timestamp trong đặc tả TUF được liên kết, sau đó so sánh cách xử lý signed.version trong examples/repo_example/basic_repo.py và các vị trí được tham chiếu của tuf/api/metadata.py. Xem lại cuộc thảo luận hiện có trước khi quyết định cách diễn đạt. Hoàn thành khi tài liệu giải thích rõ ràng thời điểm việc ký lại yêu cầu tăng phiên bản và bao gồm ví dụ được yêu cầu về timestamp đã hết hạn.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description of issue or feature request:
After reading the TUF specification and studying the basic_repo.py example, one thing remains unclear to me:
When exactly do we need to increment signed.version?
It is clear that we need to increment the signed.version after e.g. adding a new target, as detailed in the basic_repo.py example.
However, what if we only modify signed.expires, after a role has expired, without changing anything else? Do we also need to increment signed.version in that case? That would imply e.g. the version of timestamp is incremented every time it is re-signed.
In general, do we need to increment a role's signed.version every time we re-sign that role, without exception?
Current behavior:
It is not explicitly clear from the documentation when signed.version needs to be incremented.
Expected behavior:
It would be very helpful if the documentation/specification could clarify this point explicitly.
Perhaps the basic_repo.py example could also show a snippet where an expired timestamp is re-signed (without any changes to the root, targets, or snapshot metadata).
- Ngôn ngữ chính
- Python
- Star
- 1.7k
- Fork
- 304
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 17
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của theupdateframework/python-tuf
-
switch to main branch?Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
theupdateframework/python-tuf#3001 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
theupdateframework/python-tuf#2979 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Use Immutable ReleasesĐang mởenhancement github_actions
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
theupdateframework/python-tuf#2920 · 1 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Investigate/test fetcher retriesĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
theupdateframework/python-tuf#2842 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
theupdateframework/python-tuf#2836 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của theupdateframework/python-tuf
Issue tương tự
-
good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
vllm-project/vllm-metal#822 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vector-store
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 90/100
mem0ai/mem0#7461 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: chunk_span_bounds and _validated_chunk_spans reject Pydantic models ChunkSpan and AudioFileĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
BasedHardware/omi#19047 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày