x509-cert: Creating x509 certificates without allocations
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đá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
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- cryptography
Hướng nghiên cứu
Bắt đầu bằng cách xem xét các cách sử dụng hiện tại của alloc và Vec trong x509-cert, sau đó so sánh các phương án được đề xuất với heapless::Vec và tinyvec::ArrayVec. Xác định liệu một phiên bản no-alloc có khả thi hay không và các giới hạn kích thước chứng chỉ sẽ được cấu hình như thế nào; công việc được xem là hoàn tất khi thiết kế và phạm vi triển khai đã được thống nhất.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hello,
I'm interested in using x509-cert in an environment where no heap allocation is possible. I'm still new to Rust but if I understand correctly, x509-cert is working well in a no_std setting but currently require an implementation for alloc (mostly to use Vec).
Do you think that having a "no_alloc" version of x509-cert is possible and desirable? The main drawback I see is that I think it will force the developper to set a maximum size for its x509 certifcate at compilation time.
If you think it is a good idea to provide a version of x509-cert which does not require alloc, do you have a prefered approach for that (for example, replacing the use of Vec with heapless::Vec or tinyvec::ArrayVec)? If needed, I can work on it myself but I'll be happy to follow any advice you can give me.
- Ngôn ngữ chính
- Rust
- Star
- 341
- Fork
- 191
- Merge trung bình
- 1 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 19
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
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 RustCrypto/formats
-
IssuingDistributionPoint has the wrong AssociatedOid (id-pe-subjectInfoAccess)Có thể đã có người làm @eyusd đã nhận 69 ngày trước. Đang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 86/100
RustCrypto/formats#2389 · 1 bình luận ·
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
RustCrypto/formats#2366 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
RustCrypto/formats#2471 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
RustCrypto/formats#2430 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
RustCrypto/formats#2428 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của RustCrypto/formats
Issue tương tự
-
rustix::termios::Termios::OutputModes does not expost some const e.g. OLCUC for musl and macOSĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bytecodealliance/rustix#1706 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 11 ngày
-
`LazyFrameRemote` and `ExecuteRemote` sinks do not accept `Path`, like `LazyFrame` sinks do.Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Bump anybuf version to ^1.0.0Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
wormhole-foundation/wormhole#5062 ·
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 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authenticationĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100