apt-key 의 Ubuntu 매뉴얼 페이지 에는 다음과 같은 참고 사항이 포함되어 있습니다 apt-key add.

참고 :이 명령을 사용하는 대신 설명이 포함 된 이름과 "gpg"또는 "asc"를 파일 확장자로하여 /etc/apt/trusted.gpg.d/ 디렉토리에 직접 키링을 배치해야합니다.

다른 곳에서는이 조언을 본 적이 없다고 생각합니다. 자체 리포지토리를 호스팅하는 대부분의 프로젝트는 키 파일을 다운로드하여 추가한다고 말합니다 apt-key.

1. 이 조언의 동기는 무엇입니까?
2. 우분투주의입니까, 아니면 APT 기반 배포판에도 적용됩니까?

해당 프로젝트에는 오래된 지침이 있습니다. 데비안 리포지토리를 게시 하고 데비안 9 APT의 변경 사항을 알았을 때 지침을 업데이트 했기 때문에 이것을 알고 있습니다. 실제로, 매뉴얼의이 부분은 잘못된 디렉토리이므로 이제 오래되었습니다.

이것은 실제로 .d디렉토리와 관련 이 없으며 APT의 교차 사이트 취약점을 방지하는 것과 관련이 있습니다. 이전 시스템에서는 편의를 위해 별도의 키링 파일을 사용했지만 이제는 보안이 필요합니다. 당신의 보안.

이것은 취약점입니다. 두 개의 저장소 게시자 인 A와 B를 고려하십시오. Debian 8 및 그 이전 버전에서는 두 게시자의 키가 사용자 컴퓨터의 단일 글로벌 키 링에 들어갔습니다. 게시자 A가 게시자 B의 저장소 WWW 사이트를 대체 할 수있는 경우 A는 자신의 키로 서명 된 파괴적인 패키지를 게시 할 수 있습니다. A의 핵심은 결국 모든 리포지토리에 대해 전 세계적으로 신뢰할 수 있다는 것입니다.

완화는 사용자가 개별 게시자에 대해 별도의 키 링 을 사용Signed-By 하고 리포지토리 정의에서 개별 설정으로 해당 키 링을 참조하는 것 입니다. 특히 게시자 A의 키는 Signed-By리포지토리 A의 저장소 에서만 사용되며 게시자 B의 키는 Signed-By리포지토리 B의 저장소 에서만 사용됩니다 . 이러한 방식으로 게시자 A가 게시자 B의 저장소를 대체하면 APT는 파괴적인 패키지를 수락하지 않습니다. 저장소는 게시자 B가 아닌 게시자 A의 키로 서명됩니다.

현재의 /etc/apt/trusted.gpg.d메커니즘은 2005 년경부터 이쪽을 향한 오래된 빈민층의 약간 결함이있는 중간 주택입니다. 그것은 패키지화 단지 패키지 관리자에 의해 한 단계에서 설치 (또는로 다운로드 할 수 있습니다 그래서, 별도의 파일에 키링을 설정 fetch/ curl/ wget) 다른 파일로 저장됩니다. (패키지 관리자는 일반적으로 패키지 간의 파일 충돌을 처리하는 일반적인 방식으로 게시자 A의 특별한 this-is-my-repository-keyring 패키지가 게시자 B에 설치되지 않도록 처리합니다. 그러나 여전히 키 세트에 추가합니다. 모든 리포지토리에 대해 전 세계적으로 신뢰할 수 있습니다. 존재하는 전체 메커니즘은 이제 전역 적으로 신뢰할 수 없는 별도의 키링 파일을에 사용 /usr/share/keyrings/합니다.

내 지시가 이미 있습니다. ☺ 데비안 자체 리포지토리를이 메커니즘으로 옮기려는 움직임이 생겨서 더 이상 전역 적으로 신뢰할 수있는 키를 사용하지 않습니다. 찾은 "대부분의 프로젝트"에 대한 단어를 갖고 싶을 수도 있습니다. 결국, 그들은 현재 귀하에게 귀하의 컴퓨터에서 APT에 대한 전역 액세스를 그들에게 넘겨달라고 지시하고 있습니다.

추가 자료

• 다니엘 칸 길모어 (2017-05-02). 릴리스 별 키는 별도의 외부로 배송하십시오/etc/apt/trusted.gpg.d/ . 데비안 버그 # 861695.
• 다니엘 칸 길모어 (2017-07-27). 데비안 sources.list항목에는 특정 키를 가리키는 서명 옵션이 있어야합니다 . 데비안 버그 # 877012.
• "Sources.list 항목" . 타사 저장소에 연결하기위한 지침 . 데비안 위키. 2018.
• sources.list에 추가하는 것이 보안 상 위험하지 않은 이유는 무엇입니까?
• 데비안 9, APT 및 "GPG 오류 : ... InRelease : 다음 서명이 잘못되었습니다."

apt-key del는 keyid키의 의미없는 해시 인을 사용합니다.

파일 이름과 같이 의미있는 이름을 사용하여 키를 제거 할 수 있으면 더 간단합니다.

JdeBP가 말했듯이 이것은 데비안 패키지의 일부로 설치된 신뢰할 수있는 키 파일과 잘 작동합니다. 키 파일을 수동으로 설치하면 더 좋을 수도 있습니다.

현재 "초기 테스트"에있는 새로운 메커니즘에서는이 과정이 더욱 단순화되었습니다. 리포지토리 (sources.list /sources.list.d) 중 하나만 제거 / 비활성화하면 됩니다. 그러면 해당 리포지토리에 대해 구성된 키 허용이 자동으로 중지됩니다 (다른 리포지토리에서도 사용되지 않은 경우).

새로운 보안 메커니즘을 활용하는 방법을 모르겠습니다. 패키지를 사용할 경우 누군가를 신뢰해야한다고 가정합니다. 패키지 설치 프로세스는 여전히 root:-)로 실행 중 입니다.