When patching packages, design how to track modifications
@devansh6107 đang làm issue này rồi.
Từ ngày 10/10/2026.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- security
Hướng nghiên cứu
Bắt đầu bằng việc xem xét các vị trí theo dõi được đề xuất nêu trong issue: các tệp ABOUT, DejaCode và PurlDB, sau đó truy vết các quy trình downstream về lỗ hổng và đối sánh phiên bản mà chúng sẽ ảnh hưởng. Công việc được xem là hoàn tất khi một thiết kế đã được thống nhất có thể phân biệt các sửa đổi thông thường, bảo mật, tính năng, siêu dữ liệu, đổi tên và phiên bản mà không đưa vào các lookup gây ra dương tính giả hoặc âm tính giả.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
When a package is modified locally in a codebase, we should be able track these modifications and how to identify them.
Why? Because a package may have been:
- patched for a regular bug
- patched for a security vulnerability
- patched for a new or altered feature
- updated for corrected metadata (such as origin, license, dependencies)
- renamed or its version changed (or not :] )
In all these cases, we may have some problems if we do not known about this:
- we may report it as vulnerable when this is not the case
- we may not report it as vulnerable when this is the case
- we may match it it incorrectly to an upstream version or an altered version
Tracking could be done in ABOUT files, in DejaCode and the PurlDB and be used by downstream processes to avoid false negative and false positive lookups. This is especially important when we have renamed packages that are patched but where the original unpatched package and the patched version could be both vulnerable.
- Ngôn ngữ chính
- Batchfile
- Star
- 310
- Fork
- 255
- Merge trung bình
- 10 giờ 5 phút
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
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 aboutcode-org/aboutcode
-
Cross-reference OpenChain CRA Compliance ChecklistCó thể làm lại được @PaulitePavitra đã nhận 22 ngày trước và không có pull request nào đang mở. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
aboutcode-org/aboutcode#309 · 6 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
aboutcode-org/aboutcode#314 · 4 bình luận ·
-
Project: 5C: Continuous Code Compliance Control CenterCó thể làm lại được @nt5504289-oss đã nhận 35 ngày trước và không có pull request nào đang mở. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
aboutcode-org/aboutcode#291 · 3 bình luận ·
-
Remove Projects section in READMECó thể đã có người làm @mjherzog đã nhận 246 ngày trước. Đang mởdocumentation
aboutcode-org/aboutcode#277 · 6 bình luận · 1 người được giao ·
-
RFC: Create AI policyCó thể làm lại được @tdruez đã nhận 254 ngày trước và không có pull request nào đang mở. Đang mởpolicy
aboutcode-org/aboutcode#265 · 10 bình luận · 1 người được giao ·
Tất cả issue của aboutcode-org/aboutcode
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Health probes return 401 when authentication is enabled and the API is served under /orbCó thể đã có người làm @fgogolli đã nhận hôm nay. Đang mởarea: api priority: p2 size: S type: bug
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 75/100
finos/open-resource-broker#704 ·
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 68/100
processone/xmpp#117 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
superdesigndev/treg#1324 ·
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 80/100
Maintainer thường phản hồi trong vòng 1 ngày