Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Issue: Trusted strings, shell escaping and backwards compatibility.

Đang mở
  • Có gì không ổn?
#333 7 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ệ
ruby, shell
Lĩnh vực
devops, security

Hướng nghiên cứu

Bắt đầu bằng cách xem lại cuộc thảo luận trong #283 và đường dẫn execute() chung được test(), capture() và execute() sử dụng, sau đó theo dõi việc xử lý môi trường qua with() và default_env. Xác định hành vi taint và escaping dự kiến cho các điểm vào này, bao gồm cả các cảnh báo tương thích ngược được đề xuất. Công việc được xem là hoàn tất khi hành vi đã được thống nhất và tính tương thích cũng như các trường hợp lỗi của nó đã được đặc tả.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

discuss!

@ncreuschling @mattbrictson /cc

Continuing from the discussion in #283 I'd like to raise the general issue of shell escaping (shellwords) and what we mean/expect about "escaping strings" and so forth, whilst closing #283 it came to my mind that Rails using Object#taint, Object#tainted? and family works mostly pretty well.

I want to unify behavior.

I would propose the following:

  • Identify where we want to escape things, if at all:
    • Arguments to test(), capture(), execute() etc (via the common execute() function)
    • Environment variables, and values when used with with(){}
    • Environment variables when used with default_env
  • Find out if strings are tainted or not by default in the Capistrano context.
  • Find a backwards compatible way to:
    • Issue a release with warnings for "tainted" strings in the places we care about, warning that behavior will change
  • See if it makes sense to compare untrusted (the trust vernacular is deprecated) against their shellescaped counterparts, and exit with an error in that case.

I'm afraid that strings coming from the same file that is running will be trusted by default, so the whole plan falls apart, I'd have to look more closely at the API to see if the default taint value for a string is tainted, untainted, or (ideally) none.

Ideally, this would mean, I could do something like this:

SSHKit.config.default_env = {
   "$MY_LITTLE_PONY".untaint => "i should however be escaped" 
}

This would lead to us calling a literal export $MY_LITTLE_PONY=i should however be escaped, for better or worse.

Ngôn ngữ chính
Ruby
Star
1.2k
Fork
256
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của capistrano/sshkit

Tất cả issue của capistrano/sshkit

Issue tương tự

Thêm issue về Ruby

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.