10.02 // Софт // Появилась возможность работать с end-to-end gpg в консольном jabber-клиенте под *BSD
До недавнего времени единственным консольным jabber-клиентом, поддерживающим end-to-end gpg в UNIX-подобных системах был centericq, поддерживаемый Константином Клягиным. Де-факто gpg в centericq работало только под Linux, собранные же с поддержкой gpg пакеты под BSD фактически не работали (при взаимном включении gpg при приходе шифрованного сообщения centericq разлогинивал аккаунт). Кроме того, centericq корректно не подписывает шифрованные сообщения, из-за чего постоянно пишутся предупреждения в не-centericq-клиентах: "Bad signature from <jabber_id@jabber_server.org/centericq>"
На основе centericq около года назад был создан проект mcabber – также консольный jabber-клиент, который исправил ряд ошибок в дизайне и реализации в centericq, предложил другой интерфейс, и в который недавно (версия 0.9.0) была добавлена поддержка end-to-end gpg (с корректной подписью). Фактически, это первая корректная работающая реализация консольного jabber-клиента с gpg. Рекомендуется в качестве альтернативы протоколу icq и клиенту centericq.
В ряде дистрибутивов Linux mcabber-0.9.0 есть в портах, а в OpenBSD и NetBSD может быть установлен из исходников.
Заметки по инсталляции на NetBSD 3.0:
Должен быть установлен пакет gpgme-1.0.3nb3 и новый curses (ncursesw-5.6 в случае необходимости поддержки unicode, или только ncurses-5.6nb1 – у меня был установлен ncursesw-5.6). Далее, в случае привязки к OpenSSL, имеющемуся базовой системе, а не к gnutls, инсталляция происходит следующим образом:
(Инсталляция произойдёт в каталог /usr/local, но в случае надобности параметр prefix, отвечающий за выбор каталога может быть изменён).
Источник: http://www.lilotux.net/~mikael/mcabber/files/ChangeLog
комментариев: 11558 документов: 1036 редакций: 4118
Каждый закрытый подключ зашифрован отдельно, соответственно, будут отдельные запросы на подключ шифрования и подключ подписи, даже если на них одна и та же пассфраза.
Помимо багов с fifo и с OTR при disconnect'е, ещё иногда такие глюки возникают:
комментариев: 11558 документов: 1036 редакций: 4118
Сделал:
Иногда при старте возникает ошибка
Кстати, это очень плохо для usability. При старте jabber-клиента вводится пассфраза, но она, получается, только для подписи статуса. Если я после старта клиента никому не писал, пассфраза для подключа шифрования так и не появляется в памяти. Если я потом куда-то отошёл, а мне кто-то написал (и я не заметил), то сообщения так и останутся непрочитанными, поскольку jabber-клиент сделает запрос на расшифрование, а пассфразу будет ввести некому; соответственно, по истечении таймаута пассфраза более не будет принята клиентом, и он напишет об ошибке.
Можно ли как-то сделать так, чтобы пассфразы на оба подключа [и (рас)шифрования и подписи] запрашивались ещё до старта jabber-клиента? Можно, конечно, написать фиктивный что-то расшифровывающий/подписывающий скрипт, завязанный на gpg2, но это будет костыль; хотелось бы, чтоб сам gpg-agent запрашивал эти пассфразы. В man gpg-agent не заметил опций на эту тему.
Костыль будет ещё более костыльным:
Если главного секретного ключа связки нет, gpg2 отказывается делать подпись (секретным) подключом. Впрочем, раз подключ подписи всё равно спрашивается после старта jabber-клиента для подписи статуса, достаточно сделать только фиктивное расшифрование чего-нибудь (чтобы закэшировать пассфразу ещё и на подключ шифрования).
Короче, подошёл с другой стороны: запускаем обычное gpg, но с gpg-agent. Итак, в скрипте перед строками torsocks mcabber дописываем:
Вот такое костылестроение.
Только сейчас понял, что они пишут о другом. Это, кстати, как раз хорошо коррелирует с тем, что
Ключи там обычные, никто никогда на отсутствие публичных не жаловался, связка ключей извращениям также не подвергалась.
Ладно, нужный костыль в любом случае уже сделан и работает.
комментариев: 11558 документов: 1036 редакций: 4118
Согласен.
Хотел предложить именно такой вариант. Штатной функции на данный момент нет, это, насколько понимаю, архитектурное ограничение — каждую пассфразу и каждый подключ gpg-agent рассматривает отдельным объектом. В новых версиях должна появиться какая-то опция, связанная с историей вводимых пассфраз, может, это оно и есть, не знаю.
Ещё подумал: какую же охапку костылей надо сделать, чтобы получить хотя бы примерно тот же функционал, какой был до принудительной линковки gpgme с gpg-agent'ом. Вводилось это всё якобы для пущей безопасности, а в итоге, скорей всего, эффект будет ровно противоположным: люди запустят клиент; увидят, что PGP не работает, и просто отключат шифрование, т.к. мало кому захочется сидеть сутками и разбираться, что там и к чему. Такие вещи как жёсткая заивимость от gpg-agent'а надо делать опциональными. Не понимаю, каким местом думал автор gpgme (ну, или мейнтейнеры gpgme в популярных дистрах).
комментариев: 11558 документов: 1036 редакций: 4118
Чтобы был ровно один запрос пароля? Не представляю. :)