Багато людей насправді не розуміють GPGME, і це, мабуть, не допомагає, що наявна документація - це, в основному, коментар до коду, написаний у той час. Однак це дозволить забезпечити повний або майже повний програмний доступ до всього набору конфіденційності GNU, а також передбачає можливість доступу до таких речей, як libassuan, gpg-агент та різні інші компоненти. Ось чому за замовчуванням він також включає реалізацію S / MIME, яка майже нікого за межами кількох компаній, які голосно вигукнули в кінці 90-х.
В даний час GPGME включає щось на зразок 500 окремих функцій або більше і, безумовно, охоплює майже все, що ви робили з GPG в командному рядку. Однак він також містить деякі реліквії попередніх варіантів дизайну, які згодом були визначені не в правильному напрямку. Наприклад, це API з великими шматками GTK 2 в ньому. Очевидно, що це потрібно йти (і це буде, коли дозволяє час). Ще одна проблема, що виникає в наші дні, можливо, найбільша перешкода для прийняття - це те, що коли хтось каже "API", більшість кодерів не відразу думають про файли заголовків C, які потрібно скласти з власним кодом, щоб отримати доступ до речі; давайте поглянемо, що в наші дні більшість людей замислюються про щось, що РЕАЛЬНЕ або, принаймні, давайте взаємодіють з даними у форматі JSON. GPGME приблизно настільки далекий від цього, як це " s можливо отримати. Зауважте, що, хоча це повинно бути можливим, щоб вона грала добре з 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 або щось, щоб змусити його сидіти на мережевому порту, якщо хочете). Хоча це і є бездокументоване, це досить пояснює себе, якщо запустити його та трохи взаємодіяти з ним та почати з команди довідки. Крім того, це працює досить добре:
echo help | gpgme-tool > gpgme-tool-cheatsheet.txt
Він із задоволенням виконає всі основи (шифрувати, розшифровувати, підписувати, перевіряти, змінювати парольні фрази, генерувати ключі, клавіші списку, список секретних ключів, шукати конкретні ключі або вибирати їх тощо). Якщо ви хочете побачити "прихований" формат XML, спробуйте це:
echo "KEYLIST --secret-only" | gpgme-tool > secret-key-list.xml
Це не експортує секретні ключі, просто перелічіть їх та дані про них. Крім того, він буде експортований з деякою сумою вихідного формату, яку потрібно буде відфільтрувати, перш ніж щось дійсно визнає його як XML (видалити верхній рядок, перші два символи кожного наступного рядка та% 0A з кінця кожного рядка ). У будь-якому випадку, gpgme-інструмент може краще зрозуміти, що 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 / рядкового контенту, якщо він призначив або перебрав тип тексту / звичайного вмісту з десь. Коли це відбувається, то так, зазвичай потрібно перейти на 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.