Homebrew 관리자는 각 수식의 바이너리 진위를 어떻게 보장합니까?

이런 일이 일어날 수 있습니다. 거기에 대한 일반적인 합의는 가능성이 무시할 정도로 작다는 것 같습니다. Google, Amazon 등과 같은 IT 회사는 직원들이이를 사용하는 것이 완벽하기 때문에 그렇게해도 좋습니다.

와이즈 비즈 검토 작품

악의적 인 수식을 병합하는 것은 실제로 쉽지 않습니다. GitHub 계정이 필요하고 GitHub 프로필을 작성 (신뢰할 수 있도록)하는 것은 어려운 작업 (프로그래밍해야 함)이 첫 번째 방어선이 될 수 있습니다.

풀 요청 프로세스 동안 공식을보고있는 실제 사람이 있습니다. 더구나 명백한 것은 없으며, 사람들이 그곳에 존재하고 점검을한다는 사실만으로도 많은 사람들이 악의적 인 것을 제안하려고 시도하지 않는 것이 가능합니다.

가능한 공격

저장소 해킹이 실제로 발생 했습니까? 다음 예는 쉽게 정직한 실수 일 수 있기 때문에 말하기 어렵습니다.

CVE-2008-0166

2008 년에 활동적인 데비안 관리자는 "코드 정리"를 위해 OpenSSL에 버그를 도입했습니다. (https://www.schneier.com/blog/archives/2008/05/random_number_b.html)

이제 다른 가능한 공격 메커니즘으로 전환하자

타이 쪼그리고 앉기

Attacker는 널리 알려진 것과 비슷한 이름의 패키지를 업로드합니다. 사람들은 오타를 만들고 위조 된 것을 다운로드합니다.

이것은 N.P. Tschacher의 학사 논문에서 Pypi에 대해 성공적으로 입증되었습니다. incolumitas.com/2016/06/08/typosquatting-package-managers/를 참조하십시오.

모든 종류의 수동 검토가이를 포착해야하므로 Homebrew가 안전 할 것입니다.

신뢰 신뢰에 대한 반영

(https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)

Ken Thompson의 유명한 에세이는 트로이 목마를 소프트웨어 스택 (컴파일러 및 응용 프로그램 모두)에 삽입하는 절차를 안내하므로 두 가지 모두에 존재하지만 어느 쪽에서도 쉽게 감지 할 수 없습니다.

Google: 90% of our engineers use the software you wrote (Homebrew) [...]

--- Max Howell, initiator of Homebrew (https://twitter.com/mxcl/status/608682016205344768)