init writes the TLS private key at the umask mode before setting it to 0600
Maintainer thường phản hồi trong vòng 4 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
Hướng nghiên cứu
Khóa được ghi bằng std::fs::write trong crates/app/src/init_helpers.rs quanh dòng 77, sau đó được chmod thành 0600 ở dòng 83. Hãy đọc phần tạo tệp cấu hình ở dòng 328-339, nơi tệp đã được mở bằng OpenOptions với mode 0o600, và sao chép mẫu đó cho key.pem. Công việc hoàn thành khi một bài kiểm tra xác nhận tệp khóa mới có mode 0600 trước khi bất kỳ byte nào được ghi, và init vẫn hoạt động khi khóa đã tồn tại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
init generates the self-signed TLS key with std::fs::write(&key_path, ...) (crates/app/src/init_helpers.rs:77) and only then sets the file to 0600 (:83). Between the two calls key.pem has the mode the process umask gives it, 0644 under umask 022, and ~/.extenddb/tls is 0755. Another local user who opens the file in that window keeps a readable handle to the server's private key after the mode changes. The config file in the same module is created at 0600 from the start (init_helpers.rs:328-339).
init creates the key only when none exists, so the window opens once per deployment.
Reproduction
Running init five times under umask 022 in a fresh HOME while polling the file's mode: key.pem was seen at 0644 during 3 of the 5 runs and was 0600 at the end of each. Build of 1c0523c9; the code is the same on main at f49c5f823.
Expected
key.pem is created at 0600, with OpenOptions and .mode(0o600) as the config file is, so it never has a wider mode. A test checks the mode of the new file before any bytes are written to it.
- Ngôn ngữ chính
- Rust
- Star
- 517
- Fork
- 60
- Merge trung bình
- 5 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 41
Chuẩn bị môi trường
- Có Dockerfile hoặc 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 ExtendDB/extenddb
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 4 ngày
-
bug security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 4 ngày
-
extenddb version prints the first build's commit after a rebuild in the same target directoryĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 4 ngày
-
Launch-prep: scope statement + backend tiers + version policyCó thể đã có người làm @navareamol đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 3-5 ngày Mức phù hợp với người mới 65/100
ExtendDB/extenddb#662 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 4 ngày
Tất cả issue của ExtendDB/extenddb
Issue tương tự
-
example
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
rust-lang-nursery/rust-cookbook#954 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 70/100
OpenZeppelin/openzeppelin-relayer#967 ·
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 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
DecisionOutcome::label() / n_dosed(): engine-side mapping so downstream needs no wildcard armĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
src/runs.rs:1987: a missing --source-run-id now answers 400 "Source run ... does not exist", not 404Đang mởnightly-audit
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
antithesishq/snouty#602 ·
Maintainer thường phản hồi trong vòng 1 ngày