Mutt: использовать gpgme или классический gpg?


13

В вики Mutt по интеграции с GnuPG и во многих других местах (например, по умолчанию в Debian) используется классический способ подключения mutt к gnupg. То есть настраивается куча команд для gpgнепосредственного вызова . С другой стороны, есть библиотека gpgme, которая пытается стандартизировать именно это. Поиск в Интернете для "mutt gpgme" не дал мне действительно полезных результатов.

Каковы плюсы и минусы использования set crypt_use_gpgme=yesв .muttrc? Почему это так редко используется?

Ответы:


8

Многие люди действительно не понимают GPGME, и, вероятно, это не поможет тому, что существующая документация является в основном комментарием кода, написанным в то время. Тем не менее, он разрешит полный или почти полный программный доступ ко всему пакету GNU Privacy Guard, а также должен обеспечить доступ к таким вещам, как libassuan, gpg-agent и различным другим компонентам. Вот почему по умолчанию он также включает в себя реализацию S / MIME, которую практически никто, кроме нескольких компаний, громко воскликнувших в конце 90-х, использует.

В настоящее время GPGME включает в себя около 500 отдельных функций или более и определенно охватывает практически все, что вы будете делать с GPG в командной строке. Однако он также содержит некоторые остатки предыдущих вариантов дизайна, которые впоследствии были определены как неправильные. Например, это API с большими кусками GTK 2. Очевидно, что это должно пойти (и будет, когда позволит время). Другая проблема, которая возникает в наши дни, возможно, самое большое препятствие для принятия, заключается в том, что, когда кто-то говорит «API», большинство кодеров не сразу думают о файлах заголовков C, чтобы скомпилировать их с собственным кодом для доступа к объекту; давайте посмотрим правде в глаза, в наши дни большинство людей думают о чем-то, что является RESTful или, по крайней мере, позволяют им взаимодействовать с данными в формате JSON. GPGME примерно так же далек от этого можно получить. Обратите внимание, что, хотя и должно быть возможно заставить его хорошо играть с JSON, он никогда не может быть RESTful, потому что редактирование ключей не может быть. Плюс управление ключами через Интернет просто напрашивается на неприятности.

Есть также много недокументированных функций и аспектов, таких, что даже люди, работающие с программным обеспечением с момента его создания, могут все же удивляться некоторым вещам. Например, в формате XML для данных ключей, в котором есть все, кроме формальной схемы (пока она не была сгенерирована пару месяцев назад).

С другой стороны, несмотря на все хорошие вещи, которые делает Матт, он также делает некоторые довольно шокирующие вещи. Например, используется ли GPGME или нет, у Mutt не должно быть никаких оснований для кеширования парольных фраз; в любом случае его следует передать GPG (с gpg-агентом или без него). Аналогично, он должен учитывать параметры конфигурации в ~/.gnupg/gpg.confфайле (и других в этом каталоге). Конечно, установка альтернативного идентификатора ключа для разных учетных записей для изменения способа вызова команд или даже возможность указать альтернативные файлы конфигурации или целые каталоги (например,gpg --homedir ~/.gnupg-work/gpg.conf). Однако в настоящее время Mutt тратит впустую время, пытаясь решить проблемы, которые уже решаются программой, с которой он взаимодействует, например парольную фразу или управление ключами, но не позволяет получить доступ к обычным функциям GPG, многие из которых являются фантастическими для электронной почты. например, использование групповых строк для нескольких получателей или для отмены выбора ключа для определенных получателей (потому что всегда есть тот парень, который постоянно теряет свой секретный ключ или забывает пароль, и теперь у вас есть 15 открытых ключей с тем же адресом, что и UID, и поведение по умолчанию - выбрать первое совпадение, что, скорее всего, неверно). 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 действительно может сделать. Например, привязки PyME Python для GPGME пытаются автоматически сопоставить функции GPGME (и обычно достигают этого без проблем); текущий список возможностей в pyme.core.pygpgme дается до 534. Сравните это с командной строкой и GPG 1.4.20 имеет 322 варианта, в то время как 2.1.11 имеет 347 (я пропустил 2.0, поэтому не могу проверить, но это должно быть где-то между этими двумя).

Что касается предыдущего ответа, относящегося к сопоставлению ключевых команд, то это должно зависеть исключительно от параметров конфигурации и от того, разрешает ли Mutt полный доступ к GPG или нет. В настоящее время я использую Mutt с GPGME, и две упомянутые функции (почтовый ключ и ключи извлечения) хороши, хотя у Mutt действительно возникают проблемы с распознаванием содержимого PGP / in-line, если он назначил или получил тип содержимого text / plain из где-то. Когда это происходит, тогда да, обычно необходимо переключиться на Emacs или что-то еще. Тем не менее, это похоже на проблему с тем, как Mutt проверяет, является ли содержимое на самом деле просто текстом или как он проверяет содержимое формата OpenPGP. Хотя я не хотел бы ничего лучше, чем просто сказать, что мы все должны использовать PGP / MIME (и мы должны это делать),

По сути, похоже, что Mutt полагается исключительно на то, что сообщение является MIME, состоящим из нескольких частей, с одной или несколькими частями, содержащими ключ, подписи и / или зашифрованный контент, с которым он может что-либо делать. Это не будет просто искать в любом простом электронном письме, ищущем содержание, которое соответствует, но это не вина GPG или GPGME. Решение состоит в том, чтобы либо добавить эти функции в Mutt, либо открыть сообщение в чем-то с такой возможностью (например, Emacs с EPA / EasyPG, который в наши дни должен быть включен по умолчанию), либо передать сообщение прямой команде (или gpgme-tool). если хотите, но при прокачке, как правило, проще перейти прямо к обычной команде).

Что касается GPGME, то не у всех это доступно, потому что его всегда нужно компилировать из той же исходной версии, которая установлена ​​в системе. Если вы обновите GPG и не перекомпилируете GPGME для соответствия, то, скорее всего, будут проблемы. С другой стороны, обычно рекомендуется устанавливать GPG из исходных кодов, где это возможно, поэтому, если идти по пути GPGME, хорошей практикой будет просто запустить эту перекомпиляцию при обновлении GPG, и все должно быть в порядке.

Принимая во внимание, что те люди, которые полагаются исключительно на пакеты, предоставляемые их выбранным дистрибутивом, также будут подвергаться тому, что сопровождающие этих пакетов могут заботиться о поддержке, и они могут или не всегда понимают требования совместной работы GPG и GPGME. Например, пакет MacPorts для GPGME зависит от GPG 2.0.x, который, в свою очередь, конфликтует с GPG 2.1.x, поэтому большинство людей, устанавливающих 2.1, также не могут установить GPGME, даже если они явно работают вместе. Чтобы заставить GPGME работать в этом сценарии, нужно делать то, против чего рекомендует MacPorts (компилировать вещи вне системы управления портами, но внутри /opt/local). Некоторые дистрибутивы Linux могут иметь похожие проблемы.

Поэтому, если вы собираетесь использовать только PGP / MIME, не должно быть проблем с использованием интеграции GPGME, и это означает, что вам никогда не придется настраивать конкретные команды в вашем .muttrcфайле. Если вы имеете дело с PGP / in-line, то у вас возникнут проблемы, но их нельзя избежать в любом случае с Mutt, поэтому я рекомендую использовать GPGME, если вы все равно можете.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я участвовал в разработке, чтобы сделать API для API для всех не-C разработчиков, чтобы иметь возможность использовать эту вещь после капитального ремонта. Я также портировал PyME 0.9 с Python 2 на Python 3 (в настоящее время он находится в ветке GPGME, и только Python 2 версия доступна через PyPI и pip).

ОБНОВЛЕНИЕ: этот порт PyME для Python 3 теперь находится в основной ветке GPGME и доступен для PyPI как pyme3.


3

Потому что некоторые функции не работают напрямую с gpgmeинтерфейсом.

Например, следующие функции не работают в моей среде:

^K      extract-keys
<Esc>k  mail-key

когда все основные ключевые функции работают с gpgme.


0

Крипто парни параноики и понимают командную строку. библиотека новая и не проверенная, но предлагает теоретические преимущества. попробуйте, вы можете быть нашим испытательным манекеном.


1
Это не дает ответа на вопрос. Чтобы критиковать или запросить разъяснения у автора, оставьте комментарий под своим постом.
Антон

вопрос был почему не как. по общему признанию, почему больше в области психологии ...
hildred

1
Библиотека нигде не нова, она получила коммиты еще в 2000 году, возможно, раньше.
Бен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.