GnuPG 통합에 관한 Mutt 위키그리고 다른 많은 곳(데비안의 기본값 등)은 mutt를 gnupg에 연결하는 고전적인 방법을 사용합니다. 즉 gpg, 직접 호출할 수 있는 여러 명령을 구성하는 것입니다 . 반면에 gpgme이를 표준화하려는 라이브러리가 있습니다. 웹에서 "mutt gpgme"를 검색해도 정말 유용한 결과가 나오지 않았습니다.
set crypt_use_gpgme=yes에서 사용하면 어떤 장점과 단점이 있나요 .muttrc? 왜 거의 사용되지 않습니까?
답변1
많은 사람들이 실제로 GPGME를 이해하지 못하고 있으며 기존 문서는 기본적으로 당시 작성된 코드에 대한 주석이므로 도움이 되지 않을 것입니다. 그러나 전체 GNU Privacy Guard 제품군에 대한 전체 또는 거의 전체 프로그래밍 방식 액세스를 허용하고 libassuan, gpg-agent 및 기타 다양한 구성 요소에 대한 액세스도 허용해야 합니다. 이것이 기본적으로 S/MIME 구현을 포함하는 이유입니다. 90년대 후반에 이를 요구했던 몇몇 회사를 제외하고는 거의 아무도 사용하지 않습니다.
현재 GPGME에는 약 500개 이상의 개별 기능이 포함되어 있으며 명령줄에서 GPG로 수행할 수 있는 모든 기능을 다룹니다. 그러나 나중에 잘못된 방향으로 판명된 일부 이전 디자인 선택의 잔재도 포함되어 있습니다. 예를 들어 GTK 2가 많이 포함된 API입니다. 분명히 이것은 취소되어야 합니다(그리고 시간이 허락하는 대로 취소될 것입니다). 오늘날 API가 안고 있는 또 다른 문제이자 아마도 채택에 대한 가장 큰 장벽은 누군가가 "API"라고 말할 때 대부분의 프로그래머가 해당 항목에 액세스하기 위해 자신의 코드로 C 헤더 파일을 컴파일하는 것을 즉시 생각하지 않는다는 것입니다. 요즘 대부분의 사람들은 RESTful에 대해 생각하거나 최소한 JSON 형식의 데이터와 상호 작용할 수 있도록 허용하고 있습니다. GPGME는 그것과는 거리가 멀다. JSON과 잘 작동하도록 만드는 것이 가능해야 하지만 편집 키가 불가능하기 때문에 결코 RESTful이 될 수 없습니다. 게다가 네트워크를 통해 키를 관리하는 것은 문제를 야기할 뿐입니다.
소프트웨어에는 문서화되지 않은 기능과 측면이 많이 있으며, 처음부터 소프트웨어를 사용해 온 사람들조차도 여전히 몇 가지 사항에 놀랐습니다. 예를 들어, 키링 데이터의 XML 형식에는 공식 스키마(생성된 지 몇 달 전까지)를 제외한 모든 것이 포함됩니다.
반면에, Mutt는 좋은 일을 많이 하는 반면, 꽤 충격적인 일도 합니다. 예를 들어, GPGME 사용 여부에 관계없이 Mutt가 비밀번호를 캐시할 이유가 없습니다. 두 경우 모두 GPG(gpg-agent 유무에 관계없이)로 넘겨져야 합니다. 마찬가지로 ~/.gnupg/gpg.conf파일의 구성 매개변수(및 해당 디렉터리의 다른 매개변수)를 따라야 합니다 . 물론 다른 계정에 대해 대체 키 ID를 설정하여 명령 호출 방법을 변경할 수 있으며 대체 구성 파일이나 전체 디렉터리(예: gpg --homedir ~/.gnupg-work/gpg.conf)를 지정할 수도 있습니다. 그러나 현재 상태로는 Mutt는 암호나 키 관리와 같이 상호 작용하는 프로그램이 이미 해결한 문제를 해결하는 데 시간을 낭비하지만 GPG의 일반 기능에 대한 액세스를 허용하지 않습니다. 여러 수신자에 대해 또는 특정 수신자에 대해 키 선택 무시(항상 키를 잃어버리거나 비밀번호를 잊어버리는 사람이 한 명 있기 때문에 이제 UID와 동일한 주소를 가진 15개의 공개 키가 있고 기본 동작은 첫 번째 키를 선택하는 것입니다. 일치하지 않을 가능성이 높습니다). Emacs는 이 부분에서 조금 더 나았지만 파일을 얻을 수 없었습니다. 파일 gpg.conf은 일반적으로 프롬프트하려는 내용에 자동으로 응답합니다.
이제 더 유용하고 접선적으로 관련된 것을 위해 GPGME는 gpgme-tool이라는 문서화되지 않은 또 다른 멋진 기능을 제공합니다. 이는 GPGME의 기본 인터페이스이며 UNIX 소켓에서 실행됩니다(물론 원할 경우 ncat 등을 사용하여 네트워크 포트에 배치할 수 있습니다). 문서화되어 있지는 않지만, 잠시 동안 실행하고 상호 작용한 후 help 명령으로 시작하면 설명이 매우 필요합니다. 또는 다음과 같이 작동합니다.
echo help | gpgme-tool > gpgme-tool-cheatsheet.txt
모든 기본 작업(암호화, 암호 해독, 서명, 확인, 비밀번호 변경, 키 생성, 키 나열, 비밀 키 나열, 특정 키 검색 또는 선택 등)을 즐겁게 수행합니다. "숨겨진" XML 형식을 보려면 다음을 시도해 보세요.
echo "KEYLIST --secret-only" | gpgme-tool > secret-key-list.xml
이는 키를 내보내는 것이 아니라 키와 그에 관한 데이터를 나열합니다. 또한 실제로 XML로 인식하기 전에 필터링해야 하는 일부 저속한 출력 형식으로 내보냅니다(맨 위 줄, 각 후속 줄의 처음 두 문자, 각 줄 끝의 %0A 제거). 그럼에도 불구하고, gpgme-tool은 GPGME가 실제로 무엇을 할 수 있는지에 대한 더 나은 아이디어를 제공할 수 있습니다. 예를 들어, GPGME용 PyME Python 바인딩은 GPGME 함수를 자동으로 일치시키려고 시도합니다(일반적으로 어려움 없이 이를 수행합니다). pyme.core.pygpgme의 현재 함수 목록은 534입니다. 명령줄과 비교하면 GPG 1.4.20에는 322개의 옵션이 있고 2.1.11에는 347개의 옵션이 있습니다(2.0을 건너뛰었기 때문에 확인할 수는 없었지만 그 사이 어딘가에 있을 것입니다).
일치하는 키 명령에 관한 이전 답변과 마찬가지로 이는 전적으로 구성 옵션과 Mutt가 GPG에 대한 전체 액세스를 "허용"하는지 여부에 따라 결정되어야 합니다. 나는 현재 GPGME와 함께 Mutt를 사용하고 있으며 언급된 두 가지 기능(메시지 키와 추출 키)은 괜찮습니다. 비록 Mutt가 할당된 경우 PGP/인라인 콘텐츠를 인식하는 데 문제가 있거나 텍스트/일반 콘텐츠 유형을 선택하는 데 문제가 있지만 어딘가에서 어려움을 겪습니다. 이런 일이 발생하면 일반적으로 Emacs나 다른 것으로 전환해야 합니다. 그럼에도 불구하고 이는 Mutt가 콘텐츠가 실제로 텍스트인지 확인하는 방식이나 OpenPGP 형식의 콘텐츠를 확인하는 방식에 문제가 있는 것 같습니다. 내가 가장 말하고 싶은 것은 우리 모두가 PGP/MIME을 사용해야 한다는 것입니다(그리고 그래야 합니다). 불행히도 많은 사람들은 (Windows의 The Bat! 사용자처럼) 원하거나 필요하기 때문에 인라인 사용을 고집합니다. 예를 들어 Android 기기에서 암호화된 이메일을 보내야 합니다.)
기본적으로 Mutt는 여러 부분으로 구성된 MIME 메시지에만 의존하는 것으로 보이며, 그 중 하나 이상에는 키, 서명 및/또는 암호화된 콘텐츠가 포함되어 있어 모든 작업을 수행할 수 있습니다. 일반 이메일에서 일치하는 항목을 검색하는 것만으로는 충분하지 않지만 이는 GPG의 잘못도 GPGME의 잘못도 아닙니다. 해결책은 이러한 기능을 Mutt에 추가하거나 해당 기능이 있는 것(예: 요즘 기본적으로 활성화되어야 하는 EPA/EasyPG가 있는 Emacs)에서 메시지를 열거나 메시지를 직접 명령으로 파이프하는 것입니다(또는 원하는 경우 gpgme-tool을 사용하지만 파이프할 때는 일반적으로 일반 명령을 사용하는 것이 더 쉽습니다)
GPGME의 경우 항상 시스템에 설치된 동일한 소스 버전에서 컴파일해야 하기 때문에 모든 사람이 사용할 수 있는 것은 아닙니다. GPG를 업그레이드하고 일치하도록 GPGME를 다시 컴파일하지 않으면 문제가 발생할 수 있습니다. 반면에 가능하면 소스에서 GPG를 설치하는 것이 일반적으로 권장됩니다. 따라서 GPGME 경로로 이동하는 경우 GPG를 업데이트할 때 재컴파일을 실행하는 것이 좋습니다. 그러면 모든 것이 문제가 없을 것입니다.
그리고 자신이 선택한 배포판에서 제공하는 패키지에만 의존하는 사람들은 해당 패키지의 관리자가 유지 관리하려고 애쓰는 모든 것에 의해 영향을 받게 되며 GPG와 GPGME가 함께 작동하는 요구 사항을 항상 이해하거나 이해하지 못할 수도 있습니다. 예를 들어, GPGME용 MacPorts 패키지는 GPG 2.0.x에 의존하도록 설정되어 있으며 GPG 2.1.x와 충돌하도록 설정되어 있으므로 2.1을 설치하는 대부분의 사람들은 GPGME를 동시에 설치할 수 없습니다. 분명 같이 일할 것 같은데. 이 상황에서 GPGME를 작동시키려면 MacPorts가 권장하는 작업(포트 관리 시스템 외부가 아닌 내부에서 콘텐츠 컴파일 /opt/local)을 수행해야 합니다. 일부 Linux 배포판에도 비슷한 문제가 있을 수 있습니다.
따라서 PGP/MIME만 사용하려는 경우 GPGME 통합을 사용하는 데 아무런 문제가 없어야 합니다. 즉, 파일에서 특정 명령을 구성할 필요가 없습니다 .muttrc. PGP/인라인을 다루는 경우 문제가 발생하지만 Mutt를 사용하면 문제를 피할 수 있는 방법이 없으므로 가능하다면 GPGME를 사용하는 것이 좋습니다.
면책조항: 저는 C가 아닌 모든 개발자가 정밀 검사 후에 API를 사용할 수 있도록 API-to-API를 만드는 개발 노력에 참여하고 있습니다. 또한 PyME 0.9를 Python 2에서 Python 3으로 포팅했습니다(현재 위치:GPGME의 한 지점Python 2 버전만 PyPI 및 pip를 통해 사용할 수 있습니다.
업데이트: Python 3에 대한 PyME 포트는 이제 GPGME의 마스터 브랜치에 있으며 PyPI에서 pyme3으로 사용할 수 있습니다.
답변2
일부 기능은 gpgme인터페이스에서 직접 사용할 수 없기 때문입니다.
예를 들어, 다음 기능은 내 환경에서 작동하지 않습니다.
^K extract-keys
<Esc>k mail-key
모든 기본 주요 기능이 gpgme.
답변3
암호화폐 사람들은 편집증이 있으며 명령줄을 알고 있습니다. 이 라이브러리는 새롭고 테스트되지 않았지만 이론적인 장점이 있습니다. 한 번 시도해 보세요. 당신도 우리의 테스트용 더미가 될 수 있습니다.