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
комментариев: 1515 документов: 44 редакций: 5786
комментариев: 1515 документов: 44 редакций: 5786
комментариев: 61 документов: 47 редакций: 68
комментариев: 1515 документов: 44 редакций: 5786
В данном случае мотивация была, но не достаточно сильная. А если к паре кликов мышью всё не сводистя, то начинается истерика. А уж про то, чтобы вначале ознакомиться с основными идеями асимметричного крипто и PGP и речи не идёт.
Да, кстати, эти титаны с netBSD-team удосужились (не прошло и года) добавить
последнюю версию mcabber в pkgsrc. Стыд и позор да и только. Я за это время успел в оффициальную mcabber-wiki написать как поставить новые версии mcabber где
поддержка gpg уже встроена.
OTR добавлена в последнюю версию mcabber
Mcabber в Debian: no way
Есть такой баг в Debian jessie: mcabber.fifo перестало работать. Текстовые файлы больше легко из консоли не перешлёшь. ☹ При посылке в него строк, приглашение командной строки не возвращается, а сообщение не отправляется. Неприятно, но пережить можно, хуже другой баг:
По факту это изначает, что использовать mcabber с PGP нельзя, потому что пассфраза запрашивается:
Всем по??й, никто не фиксит. Поверхностный осмотр говорит, что пакет завязан на gpg2 со всеми вытекающими. Это было бы ещё полбеды, если б оно работало хотя бы как-то, но тут речь идёт фактически о полной неработоспособности. На gpg2 жалуются в джабберах все, даже если номинально это работает: теряются сообщения; если вовремя не ввёл пассфразу, они не расшифровываются; часто не расшифровываются оффлайновые сообщения и т.д. и т.п. Разработчики с приходом gpg2 сделали всем хорошо. Вообще, сама идея, что в минималистичном оконном менеджере какая-то фигнюшка с окошечком, да ещё завязанная на gtk, постоянно лезет всюду, куда не нужно, сразу кажется поганой. Да, речь идёт о pinentry. В man gpg2 сразу предостерегают от попыток вмешаться в процесс опоганивания, в выражениях мудачьё не стесняется:А разработчики этих интерфейсов не dummy? Есть у меня сомнения на этот счёт:
Первый способ пофикса — установить старый deb-пакет mcabber'а через dpkg -i, где таких проблем нет. Оказывается, вариант не работает, т.к. mcabber слинкован с более старыми libotr, чем есть в системе. Второй вариант — скомпилить с сорсов. Однако, проект тяжёлый, хоть и консольный, у него много зависимостей, поэтому проще воспользоваться портами. Итак,
pkgsrc на Debian: более-менее готовый способ прохода квеста
Общая информация приведена тут. Делаем:
PGP-подписи пакетов вроде есть и работают, но в деталях внутренней кухни я не разбирался. Даже не могу гарантировать, что подписи для скачиваемых тарболлов проверяются по умолчанию при внесении нижеуказанных опций.
п-рас и кого, не разобравшись, следует обхамитьвсему виной. Итак, всему виной не mcabber, а gpgme, которую не то автор, не то мейнтейнер, решили начать линковать с gpg2, а не с gpg. Сам mcabber вообще ничего про это не знает, т.к. завязан только на gpgme:Ладно, может хотя бы теперь пассфраза не будет на каждое сообщение запрашиваться? Надежда какая-то есть. Вообще, тут есть глобально, о чём подумать. В Debian ведь тоже всё завязалось на gpg2 после включения зависимости в gpgme... В частности, это всё похабит и для других программ, таких как mutt и т.п. Кто-то решил, что десктоп должен выглядеть именно таким, с pinentry и не иначе. И одной зависимостью такая кабала была включена в массу программ. Ведь жили же десять лет без этой дури, но нет, кто-то решил, что давно пришло время всё сломать и претворить gpg2-страхи из страшилок в интернет-статьях в повседневный быт. Пусть народ потрахается по полной, не зря ж эту дрянь кто-то писал. pulseudio и systemd тоже вот не зря писали, поэтому вчера если это было «вас пока не касается», то сегодня это «извините, но мы решили, что пусть это будет дефолтом в вашей ОС, да».
Короче, возвращаемся в директорию mcabber, делаем для него bmake и bmake install. Быстро сказка сказывается, да не быстро дело делается, вот что в итоге будет скомпилено и установлено:
Очень повезло, что ни один из этих гигантских пакетов не вылетел с непонятной ошибкой при компиляции.
Печальные итоги
mcabber из pkgsrc:
Вряд ли этой рекомендации вняли мейнтейнеры pkgsrc-пакетов при учёте зависимостей.
Да, не у всех сказок хороший конец. У этой плохой. П-сы победили. Наверно, я неопытный и глупый пользователь, так и не смог найти подход к софту. Целый день убит зазря, все эксперименты не имели смысла. Приходится принимать соломоново решение: сбрасываем пароль с PGP-ключа, используемого в mcabber, и все проблемы как рукой снимаются ценой появления вопросов к безопасности. И после этого ещё кто-то интересуется, почему я зациклился на pinentry и т.п. штуках. Хочу добавить, что мне известно, что аналогичные проблемы с запросом пассфразы, хоть и не такие фатальные, есть и в других Debian-/Linux-дистрах, многие жалуются и какими-то костылями пытаются разрулить. В лучшем случае всё сводится к «извини, я тупанул с пассфразой, и снова всё потерялось, перешли все сообщения повторно», которое может возникнуть два и более раз подряд.
Это даже не вопросы софта, это исключительно политические вопросы. С чего какой-то мудак решил, что gpg2 и «gpgsm» всем позарез нужно? Почему кто-то за всех решил, с чем будут слинкованы все пакеты по дефолту? Можно ведь найти конкретных людей и конкретные фамилии, которые внесли эти изменения, поднять срач, призвать к ответу,
пригрозить санкциями, встретить ночью в подъезде.Почему тысячи людей по всему миру должны плясать под дудку какого-то дурака, у которого зачесались ручки внести изменения в конфигурацию таких важных пакетов? Почему я должен тратить своё жизненное и рабочее время на разруливание всех этих проблем?Можно, конечно, сказать, что мало ли какие есть джаббер-клиенты, пакет не так важен. Но хороших, которые умеют и OTR и PGP, да ещё и с кучей полезных плюшек и при этом консольных в альтернативе нет ни одного. Т.е. либо сильно поступаемся юзабилити, либо жрём кактус. И джаббер — это один из самых важных пакетов в ОС, фактически основное окно во внешний мир. Ну не ICQ же со скайпом использовать со всеми и вся, в конце концов, и не соцсети. Torchat — тоже не дело, а onionphone не допилен. Некуда податься.
P.S. Максима о том, что обновление софта всегда приводит к тому, что всё рушится и перестаёт работать, подтверждается со 100%-ой вероятностью.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
Фатальная — да.
Руками я его не запускал. Поидее это должен делать джаббер-клиент. Во время работы джаббер-клиента он висит в списке процессов, т.е. запущен. Но мысль интересная, спасибо. Можно попытаться запустить руками и поиграться с конфигами/опциями, вдруг взлетит всё-таки.
Для начала надо добиться, чтоб он вообще работал, хотя бы какой-то. Думаю, тут не влияет, какая программа запускается.
А какой из них безопаснее? Или всё равно? В обоих случаях будет создаваться дополнительное окно для ввода пассфразы и защиты от «X-sniffing attacks» (см. опцию --no-grab)?
комментариев: 11558 документов: 1036 редакций: 4118
So here's your problem. ©
При таком автостарте кэширование не работает.
А фиг, она вообще непонятно где работает, может, только в совсем уж свежих версиях pinentry. Ещё есть вариант с DISPLAY="" (точно работает, по её наличию как раз и определяется, запускать ли гуишный вариант или консольный) и с симлинком с pinentry на pinentry-curses (совсем уж дёшево и сердито).
Только в гуишном варианте.
Значит, он безопасней.
Вообще, принудительный запрет grab'а окон заставляет задуматься. Любой троян, запущенный под тем же юзером, тоже может так делать? Никаких же особых прав не надо, так? А заблокировать клавиши переключения в текстовую консоль он тоже может?
Почему?! Это баг или фича? В man gpg-agent написано, что по умолчанию пассфраза кэшируется на 600 секунд.
комментариев: 11558 документов: 1036 редакций: 4118
Очевидно, что да.
Вероятно, ограничение, так глубоко не лазил. Для корректной работы gpg и gpg-agent требуется IPC-интерфейс в виде Unix-сокета. Когда пользователь порождает gpg-agent, путь к этому сокету и PID gpg-agent сохраняются в переменных среды, и запускаемый позднее gpg получает к ним доступ. Видимо, если запуск происходит в обратном порядке (gpg порождает gpg-agent), у gpg нет доступа к этой информации. Почему оно так, сказать затрудняюсь.
Похоже, вы правы. По крайней мере, запросы пароля на каждое сообщение при корректном старте исчезают. Более того, сам mcabber более не запрашивает пароль при старте, это делает только pinentry. Правда, непонятно, почему он хотя и спрашивает пароль для подписи статуса, но не кэширует его, т.к. при тут же посланных сообщениях пароль запрашивается снова (хоть и один раз, но всё равно). Может ли быть такое, что при запуске jabber-клиент принудительно инструктирует gpg-agent не кэшировать пассфразу несмотря на его дефолты? Такое впечатление, что запросы пароля на смену статуса и на расшифровку сообщений как-то слабо между собой связаны, хотя чёткого паттерна не видно. При первом старте идёт стабильно 2 запроса: на установку статуса и на расшифровку первого полученного сообщения (если есть). Однако, при некоторых последующих стартах jabber-клиента может быть так, что пароль не запрашивается вообще ни на что, т.к. он уже сидит в памяти агента. Короче, как-то глючно и слабопредсказуемо, но работает.
Обнаружился ещё один глюк: если сделать /disconnect, а потом снова /connect, то происходит предельно странное:
- mcabber пытается сгенерировать OTR-ключ, хотя все настройки OTR отключены в конфиге.
- mcabber генерирует не свой ключ, а ключ конакта из ростера! Это вообще полнейшая дичь (это видно по имени ключевого файла в логах).
Может быть, есть какое-то нетривиальное инфицирование одного jabber-профиля другим, но я ничего такого в своих конфигах не нашёл.