Httpie: HTTPie는 시스템 인증서를 무시합니다.

ssl.get_default_verify_paths ()를 사용하여 기본 경로를 얻는 것이 합리적입니까?

다음과 같은 행동을 제안합니다.

--verify에 no 또는 yes 이외의 매개 변수가 전달되면 매개 변수를 요청에 전달합니다.

--verify가 yes로 설정된 경우 :
1) REQUESTS_CA_BUNDLE이 설정된 경우 True를 요청 확인에 전달합니다.
2) elif 환경 변수 ssl.get_default_verify_paths (). openssl_cafile_env가 설정되어 확인 요청에 전달합니다.
4) elif 환경 변수 ssl.get_default_verify_paths (). openssl_capath_env는 확인 요청을 통과하도록 설정됩니다.
5) elif ssl.get_default_verify_paths (). capath가 None이 아닙니다. 확인 요청에 전달합니다.
6) 그렇지 않으면 True를 전달하여 요청 확인

그러나 ssl.get_default_verify_paths는 python3.4 이후에만 사용할 수 있습니다.

@luv 는 3.4+ 및 2.7.10+에서만 사용할 수있을뿐만 아니라 모든 플랫폼에서 작동하지 않습니다. 이것이 사람들을 위해 이것을 해결하기 위해 요청이 자체 문제를 해결하는 이유입니다. httpie에 지속적으로 댓글을 달지 마세요. 이것은 httpie IMO가 아닌 요청에 존재하는 문제입니다.

@ sigmavirus24 뭐야 ? 끊임없이 댓글을다는 것이 무슨 뜻인지 모르겠지만, 어쨌든 httpie 기고자도 아닙니다. 나는 단지 어리석은 트롤이라고 가정합니다 : /

작동하는 구현이 어떻게 생겼는지 확인하기 위해 curl 소스 코드를 한 눈에보기 ....

모든 amiga 및 VMS ifdef와 다양한 ssl 라이브러리에 대한 지원을 무시하고 실제로는 어리 석고 openssl X509_ * 조회 방법을 사용하지 않습니다 (예 : Python SSL 모듈의 get_default_verify_paths ()에서 사용됨).

대신 curl은 컴파일 타임에 알려진 여러 위치를 반복 한 다음 (이 m4dness https://github.com/curl/curl/blob/master/acinclude.m4#L2560 참조) 명시 적으로 (CURL_CA_BUNDLE 및 ) 런타임시 SSL_CERT_DIR 및 SSL_CERT_FILE 환경 변수 (다시 X509_get_default_cert_file_env ()와 같은 항목을 사용하지 않음). 그게 다야.

그렇다면 순수한 파이썬에서 동일한 접근 방식을 구현하는 것은 어떻습니까? (예, 지옥처럼 빠르고 더러워 보이지만 curl에서는 작동합니다!) 그러나 Windows (ssl.enum_certificates?) 및 OS X 지원 추가 (여기에서 확실하지는 않지만 Python은 OS X 10.6 이상에서 사과 제공 openssl 라이브러리를 사용하는 것 같습니다.) 이미 괜찮을 것입니다!).

@luv 신고 @ sigmavirus24 는

이 문제는 3.0.0 릴리스까지 요청에서 수정되지 않습니다 ... 가능한 호환성 문제로 인해 SSL_CERT_FILE도 지원되지 않습니다 https://github.com/kennethreitz/requests/pull/2903

btw. 나는 무례하다는 뜻이 아니었다. 나는 정말로 s / 그가 트롤링하고 있다고 생각했다. :) 나는 문제에 대한 해결책을 찾기 위해 나섰고 한 번도 프로젝트에 기여하지 않은 사람을 찾았다. 그런 적대적인 반응에 정말 놀랐습니다) 기본적으로 나에게 닥치라고 말하고있었습니다 : /

@luv 닥치 라고 말하지

마지막으로 코드 기여 만이 프로젝트에 기여하는 것은 아닙니다. 프로젝트에 대한 모든 기여를보고 싶다면 octohatrack 과 같은 프로젝트를 사용할 수 있습니다. 나는 그들이 매우 요청 '개발을 수행 할 시간이 없기 때문에 @jkbrzt에 대한 httpie에 버그 관련 여러 요청에 응답했습니다. 여기에서 요청 관련 버그를 발견하면 99 %의 시간이 이미 처리 중이기 때문에 응답합니다. 운 좋게도 @jkbrzt를 위해 나는 이전에 좋지 않은 (그리고 몇 배 더 나쁜) 취급을

참고로 "they"는 "s / he"만큼 많은 문자이며 한 사람을 지칭하는 데에도 사용될 수 있기 때문에 훨씬 더 일반적으로 적용됩니다.

그래서 우리는이 문제를 해결하고 있습니까?

@jkbrzt 나는 이것을 버그가 아닌 기능이라고 부를 것입니다. Requests는 Windows, * nixes 및 BSD에서 동일하게 작동하며 실제로 Requests의 많은 시스템 배포는 이러한 동작을 적극적으로 제거하고 시스템 인증서 저장소 / 번들을 가리 킵니다. 따라서 사용자가이 동작을 필요로하는 경우 시스템 배포자가 HTTPie (및 가능하면 시스템 패키지 HTTPie)를 사용하여 패키징 한 Request 버전을 사용할 수 있습니다.

"이 문제 해결"에 관해서는 고정 정의에 따라 다릅니다. 이것은 요청에 추가 될 기능입니다. 어느 시점에서 HTTPie는 무료로 동작을 얻습니다. HTTPie가 대신 이것을 더 높은 우선 순위로 간주하면 (@jkbrzt가 적합하다고 생각하는 대로 수행 할 수 있음) 개발 노력을 복제하여이 작업을 더 빨리 수행 할 수 있습니다.

Linux, @luv를 사용하는 것처럼

apt를 통해 설치된 HTTPie와 동일한 문제 (ubuntu 14.04lts)

@luv 14.04 및 16.04에 대한 요청이 시스템 인증서 저장소를 사용한다는 사실을 알고 있기 때문에 놀랍습니다. Requests를 어떻게 설치 했습니까?

httpie의 우분투 배포판이 사용되는지 확인하기 위해 모든 "요청"및 "httpie"버전을 제거했으며 PyPI의 httpie를 여전히 사용하고있었습니다. Ubuntu httpie가 "ImportError : cannot import name is_windows"와 함께 실패하며 이는 알려진 문제입니다.

처음에 python3을 사용해야했기 때문에 "pip3 uninstall"을 실행하는 것을 잊고 "pip uninstall"만 실행 한 것 같습니다.

761 명에게 내 httpie 설정에 대한 설명과 함께 "스팸"을 보낸 것에 사과드립니다.

저는 Gentoo Linux, httpie-0.9.9 및 requests-2.18.4 (최신 Gentoo에서 사용 가능)를 사용하고 있습니다. 다른 도구 (openssl s_client, sslclient, curl)는 설치된 로컬 CA 인증서를 감지하고 제대로 작동하지만 httpie는 실패합니다.

$ openssl s_client -quiet -connect localhost:8082                                              
depth=1 CN = Local CA home.lan
verify return:1
depth=0 CN = localhost
verify return:1
^C
$ http -v https://localhost:8082/                                                              

http: error: SSLError: HTTPSConnectionPool(host='localhost', port=8082): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)) while doing GET request to URL: https://localhost:8082/

작동하도록 업데이트해야합니까?

@powerman 그 패키지의 젠투 재배포 자에게 더 적절한 질문입니다.

@ sigmavirus24 왜 그렇습니까? 내 질문은 이러한 요청 / httpie 버전이 시스템 CA 목록을 처리해야하는지 여부입니다. 그렇다면 내 시스템에 무언가 잘못 구성되었거나 버그가있을 수 있습니다. 그렇지 않다면 어떤 버전이 필요합니다.

@powerman 아무것도 변경되지 않았습니다. 둘 다 시스템 인증서 번들을 지원하지 않지만 배포의 패키지 관리자에서 둘 다 설치 한 경우 소프트웨어를 패치하여 사용했을 가능성이 있습니다. 젠투에서 사용 가능한 패키지를 사용하고 시스템 인증서를 사용하지 않는다면 젠투 문제입니다.

여기에 대해 한 가지 추가 설명을 추가하겠습니다. SSL 요청을 할 때 사용자와 프록시 사이에 보안 터널을 설정 한 다음 프록시와 대상 사이에 또 ​​다른 터널을 설정하도록 특별히 설계된 프록시를 사용합니다. 이렇게하면 프록시를 통과하는 트래픽을 안전하게 모니터링하여 아무도 불쾌한 일을하여 숨기려고하지 않는지 확인할 수 있습니다. 이것은 불행히도 httpie가 다시 가져 오는 인증서가 신뢰할 수 없음을 의미합니다 (시스템 루트에 있지만 httpie가 사용하지 않기 때문에).

실제로 NixOS에서 동일한 문제를 재현 할 수 있습니다.

4 년 이상 후 ...