Validation errors are hard to present safely to the user (missing abstraction)
Maintainer thường phản hồi trong vòng 1 ngày
@jkowalleck đang làm issue này rồi.
Từ ngày 1/7/2025.
Đá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
- 35/100
Hướng nghiên cứu
Bắt đầu với cyclonedx/validation/init.py và các entry point validation/json.py và validation/xml.py được tham chiếu trong issue, sau đó tái hiện các ví dụ bằng cách sử dụng các tệp schemaTestData được liệt kê. Công việc được xem là hoàn tất khi việc validation JSON và XML cung cấp một path ổn định và một message an toàn thông qua một abstraction chung, đồng thời giữ lại lỗi thô bên dưới trong data.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
https://cyclonedx-python-library.readthedocs.io/en/v10.2.0/autoapi/cyclonedx/validation/
We are using both JSON and XML inputs, and when something is wrong with the input, it is not easy to get the location of the problem or even what is wrong can be hidden in a multi-MB message.
One of the problem is, that the underlying libraries make it hard:
jsonschemaincludes all the input (instance) in the error message, which in the SBOM case can be quite big, producing the above mentioned multi-MB message (thisuniqueItemscheck can fail on e.g. thedependencies):yield ValidationError(f"{instance!r} has non-unique elements")- in the xml case, somehow the easiest solution was to get the error from the logs: https://github.com/CycloneDX/cyclonedx-python-lib/blob/1a932a2ab00efb029c7b685cba7d9e5af3b7ea19/cyclonedx/validation/xml.py#L71
The other problem is, that CycloneDX makes no attempt at transforming these different object types into something sensible and type-safe for users, the raw objects are simply leaked through the interface as is in https://github.com/CycloneDX/cyclonedx-python-lib/blob/1a932a2ab00efb029c7b685cba7d9e5af3b7ea19/cyclonedx/validation/__init__.py#L36
Code samples triggering long messages:
from cyclonedx.validation.json import JsonStrictValidator
from cyclonedx.schema import SchemaVersion
test_data_file = "tests/_data/schemaTestData/1.2/invalid-license-id-1.2.json"
schema_version = SchemaVersion.V1_2
validator = JsonStrictValidator(schema_version)
with open(test_data_file) as tdfh:
test_data = tdfh.read()
validation_error = validator.validate_str(test_data)
print(str(validation_error))
This message is 35508 characters long - 767 lines!
from cyclonedx.validation.xml import XmlValidator
from cyclonedx.schema import SchemaVersion
test_data_file = "tests/_data/schemaTestData/1.1/invalid-license-id-1.1.xml"
schema_version = SchemaVersion.V1_1
validator = XmlValidator(schema_version)
with open(test_data_file) as tdfh:
test_data = tdfh.read()
validation_error = validator.validate_str(test_data)
print(str(validation_error))
This message is 12423 characters long - 1 line.
I would expect the errors returned/raised by CycloneDX something like below:
class ValidationError:
# abstract class
data: Any
"raw problem, for debugging"
path: str
message: str
class XmlValidationError(ValidationError):
# this subclass knows what data is
@property
def path(self):
return self.data.path
@property
def message(self):
return self.data.message
class JsonValidationError(ValidationError):
# this subclass knows what data is
@property
def path(self):
return self.data.json_path
@property
def message(self):
# ensures the error is transformed to something sensible
# resolving a problem caused by using jsonscheme for CycloneDX users
instance = repr(self.data.instance)
return self.data.message.replace(instance, shortened(instance))
# where shortened(long_text) ~ 'first n ... last n', that is the middle of the string replaced
# this would still add some context, but it will be safe to display
These would provide a stable abstraction over generally useful validation error properties, and also hide implementation details from users, like third party objects lxml.etree._LogEntry and jsonschema.exceptions.ValidationError. The above proposal is also backward compatible, keeping data intact, if someone depends on it.
- Ngôn ngữ chính
- Python
- Star
- 117
- Fork
- 67
- Merge trung bình
- 21 giờ 9 phút
- Pull request đã merge (30 ngày)
- 3
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 CycloneDX/cyclonedx-python-lib
-
[PERF] Quadratic (O(N^2)) serialization time for large BOMs — `Bom.validate()` → `register_dependency()` linear scanCó thể đã có người làm @inspired-geek đã nhận 109 ngày trước. Đang mởperformance
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 36/100
CycloneDX/cyclonedx-python-lib#1006 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
tests: test all model enumsCó thể làm lại được @jkowalleck đã nhận 125 ngày trước và không có pull request nào đang mở. Đang mởQA
CycloneDX/cyclonedx-python-lib#991 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feat(deps)!: make all de/serialization libraries optionalCó thể làm lại được @Simoh23999 đã nhận 73 ngày trước và không có pull request nào đang mở. Đang mởbreaking change dependencies
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
CycloneDX/cyclonedx-python-lib#979 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feat: Add support for Component signatureCó thể đã có người làm @wiebe-vandendriessche đã nhận 124 ngày trước. Đang mởenhancement help wanted schema 1.4
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
CycloneDX/cyclonedx-python-lib#978 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
chore: have coverage uploaded consitentlyCó thể làm lại được @jkowalleck đã nhận 171 ngày trước và không có pull request nào đang mở. Đang mởchore
CycloneDX/cyclonedx-python-lib#966 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của CycloneDX/cyclonedx-python-lib
Issue tương tự
-
Claiming namespace `jft63`Đang mởnamespace operations
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
EclipseFdn/open-vsx.org#14043 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
netbox status: needs triage type: bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
netbox-community/netbox#23376 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feedback simulation workshop
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
githubnext/gh-aw-workshop#4455 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Triage 🩺
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Container scenario crashes without expected_recovery_time, kube DNS example uses retry_waitĐang mởneeds-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
krkn-chaos/krkn#1627 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày