id: Гость   вход   регистрация
текущее время 18:01 05/12/2019
Владелец: spinore (создано 10/02/2007 16:37), редакция от 13/02/2007 13:45 (автор: SATtva) Печать
Категории: софт, gnupg, стандарты, xmpp, свободный софт, операционные системы, расширения
https://www.pgpru.com/Новости/2007/02-10-ПоявиласьВозможностьРаботатьСEnd-to-endGpgВКонсольномJabber-клиентеПодBSD
создать
просмотр
редакции
ссылки

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


 
На страницу: 1, 2, 3 След.
Комментарии [скрыть комментарии/форму]
— Maxim (13/02/2007 10:17)   <#>
Хм... а как я уже больше года в Tkabber шлю шифрованные сообщения и подписываю их?
— spinore (13/02/2007 20:37)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
tkabber – это не консольный клиент. И под текстовым терминалом вы его на запустите. А mcabber будет работать в любом терминале: хоть графиеском – хоть текстовом. Точнее говоря, можно из tkabber сделать чисто консольный front-end, но это не так просто и быстро и пока ещё никто не удосужился.
— spinore (08/06/2007 05:47)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Вчера пересаживал одного товарища с icq на jabber c end-to-end gpg. В результате убитых 4 часов чистого времени общения онлайн его руками зарегистрировал аккаунт psi, инсталлировал gpg, создал, экспортировал и импортировал нужные ключи, а также подружил с ними psi. И всё-таки это крайне дорогое удовольствие пересаживать кого-то на jabber... Просто нет слов. А с некоторыми было так, что после нескольких убитых часов и даже благополучного законнекта в jabber получал сообщение "jabber не работает" на котором всё и заканчивалось. Неужали это так сложно?
— mellon (08/06/2007 08:50, исправлен 08/06/2007 08:53)   профиль/связь   <#>
комментариев: 61   документов: 47   редакций: 68
Если мотивации у подопытного (ой! То есть подопечного:) нет, то это действительно сложно.
— spinore (08/06/2007 23:16)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Если мотивации у подопытного (ой! То есть подопечного:) нет, то это действительно сложно.

В данном случае мотивация была, но не достаточно сильная. А если к паре кликов мышью всё не сводистя, то начинается истерика. А уж про то, чтобы вначале ознакомиться с основными идеями асимметричного крипто и PGP и речи не идёт.

Да, кстати, эти титаны с netBSD-team удосужились (не прошло и года) добавить
последнюю версию mcabber в pkgsrc. Стыд и позор да и только. Я за это время успел в оффициальную mcabber-wiki написать как поставить новые версии mcabber где
поддержка gpg уже встроена.
— Гость (28/11/2007 22:23)   <#>
Приятная новость:
OTR добавлена в последнюю версию mcabber
— дАртаньян (31/01/2015 14:11)   <#>

Mcabber в Debian: no way


Есть такой баг в Debian jessie: mcabber.fifo перестало работать. Текстовые файлы больше легко из консоли не перешлёшь. ☹ При посылке в него строк, приглашение командной строки не возвращается, а сообщение не отправляется. Неприятно, но пережить можно, хуже другой баг:

The PGP passhrase provided either at startup or with pgp_passphrase config option is silently ignored. Mcabber asks for passphrase at startup when there is no GPG_AGENT_INFO set in environment, but nevertheless every time the key is needed it then spawns a gpg-agent to ask for passphrase instead of using the one provided at startup.

По факту это изначает, что использовать mcabber с PGP нельзя, потому что пассфраза запрашивается:

  1. Самим mcabber'ом при старте.
  2. pinentry при старте mcabber'а.
  3. pinentry при смене статуса в mcabber'е.
  4. pinentry при начале OTR-сесси.
  5. pinentry при получении каждого PGP-шифрованного сообщения, как онлайнового, так и оффлайнового.

Всем по??й, никто не фиксит. Поверхностный осмотр говорит, что пакет завязан на gpg2 со всеми вытекающими. Это было бы ещё полбеды, если б оно работало хотя бы как-то, но тут речь идёт фактически о полной неработоспособности. На gpg2 жалуются в джабберах все, даже если номинально это работает: теряются сообщения; если вовремя не ввёл пассфразу, они не расшифровываются; часто не расшифровываются оффлайновые сообщения и т.д. и т.п. Разработчики с приходом gpg2 сделали всем хорошо. Вообще, сама идея, что в минималистичном оконном менеджере какая-то фигнюшка с окошечком, да ещё завязанная на gtk, постоянно лезет всюду, куда не нужно, сразу кажется поганой. Да, речь идёт о pinentry. В man gpg2 сразу предостерегают от попыток вмешаться в процесс опоганивания, в выражениях мудачьё не стесняется:

--no-use-agent
This is dummy option. gpg2 always requires the agent.

А разработчики этих интерфейсов не dummy? Есть у меня сомнения на этот счёт:

Есть ли какое-то коцептуальное отличие случая «gpg+pinentry+пассфраза» от «PGP-ключ лежит на диске нешифрованным (ограничиваемся только дисковым шифрованием)»?
Если под одним пользователем на одной системе, то, в пределе, без разницы.

Первый способ пофикса — установить старый deb-пакет mcabber'а через dpkg -i, где таких проблем нет. Оказывается, вариант не работает, т.к. mcabber слинкован с более старыми libotr, чем есть в системе. Второй вариант — скомпилить с сорсов. Однако, проект тяжёлый, хоть и консольный, у него много зависимостей, поэтому проще воспользоваться портами. Итак,

pkgsrc на Debian: более-менее готовый способ прохода квеста


Общая информация приведена тут. Делаем:

  1. Ставим компиляторы:
    # apt-get --no-install-recommends install gcc
    # apt-get --no-install-recommends install clang-3.5
    # apt-get --no-install-recommends install g++

  1. Берём pkgsrc-ключи и устанавливаем их в пользовательский keyring (pkgsrc будем ставить в юзерский $HOME, всё локально). Списки ключей девелоперов имеются. Как к ним установить доверие — непонятно, да и можно ли? Ладно, это философский вопрос. Самое простое — найти того, кто входит в debian-keyring или ему подобные и при этом подписал pkgsrc-ключ. Поверхностный поиск говорит, что в Debian-кейрингах нет ключей с мейлами на netbsd.org. Гугление «trust path debian to netbsd» даёт вариант в 4-5 хопов и там инструменты полагаются только на доверенный пул (strong set) PGP-ключей, далеко не все в него входят. Не знаю, есть ли готовые инструменты, дающие ответ на вопрос «найти ключ в заданном кейринге, который по подписям даёт кратчайший путь к какому-либо ключу с мейлом на заданном домене», причём безотносительно вхождения этих ключей в strong set.

    PGP-подписи пакетов вроде есть и работают, но в деталях внутренней кухни я не разбирался. Даже не могу гарантировать, что подписи для скачиваемых тарболлов проверяются по умолчанию при внесении нижеуказанных опций.

  1. Устанавливаем собственно порты:
    $ cd ~/
    $ proxychains env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot \
    checkout -P pkgsrc
    Оно требует принять отпечаток SSH-ключа. Не знаю, есть ли возможность проверить его надёжным образом (через PGP), у меня он был такой:
    The authenticity of host 'anoncvs.netbsd.org (149.20.53.68)' can't be established.
    RSA key fingerprint is a0:b1:35:d7:56:be:2c:30:78:b0:21:df:43:d9:64:5c.
    Кстати, отпечаток зависит от типа ключа, а тип ключа выбирается по согласованию версий ssh-клиента и ssh-сервера, поэтому если на старой машине уже есть какой-то отпечаток, на новой он может не подойти для верификации, поскольку там использовались, к примеру, DSA-ключи, а тут выбирается эллиптика.

  1. Бутстрэпимся:
    $ cd ~/pkgsrc/bootstrap
    SH=/bin/bash ./bootstrap --unprivileged
    Оно должно пройти без ошибок. Если есть ошибки, надо разбираться и фиксить их.

  1. Добавляем инфу про требование PGP в конфиги: SIGN_PACKAGES=gpg идёт в ~/pkg/etc/mk.conf, а GPG=/usr/bin/gpg и VERIFIED_INSTALLATIONS=always — в ~/pkg/etc/pkg_install.conf.

  1. Скачиваем БД известных проблем и уязвимостей pkgsrc:
    $ proxychains  pkg_admin fetch-pkg-vulnerabilities -s
    ProxyChains-3.1 (http://proxychains.sf.net)
    |DNS-request| ftp.NetBSD.org
    |S-chain|-<>-127.0.0.1:9050-<><>-4.2.2.2:53-<><>-OK
    |DNS-response| ftp.NetBSD.org is 199.233.217.226
    |S-chain|-<>-127.0.0.1:9050-<><>-199.233.217.226:80-<><>-OK
    gpg: Signature made Thu 29 Jan 2015 10:29:53 AM UTC using RSA key ID 7DBE3F8C
    gpg: Good signature from "pkgsrc Security Team <pkgsrc-security@pkgsrc.org>"
    gpg:                 aka "pkgsrc Security Team <pkgsrc-security@NetBSD.org>"
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: C5E8 EF17 A382 E923 E338  6898 0F03 B7A9 7DBE 3F8C
    Можно сразу проверить подпись на целевом пакете:
    $ pkg_admin audit -s mcabber
    gpg: Signature made Thu 29 Jan 2015 10:29:53 AM UTC using RSA key ID 7DBE3F8C
    gpg: Good signature from "pkgsrc Security Team <pkgsrc-security@pkgsrc.org>"
    gpg:                 aka "pkgsrc Security Team <pkgsrc-security@NetBSD.org>"
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: C5E8 EF17 A382 E923 E338  6898 0F03 B7A9 7DBE 3F8C

  1. Установка идёт стандартным образом
    $ cd ~/pkgsrc/chat/mcabber
    $ proxychains bmake
    но начинать с неё не надо, потому что в процессе было обнаружено, кто п-рас и кого, не разобравшись, следует обхамить всему виной. Итак, всему виной не mcabber, а gpgme, которую не то автор, не то мейнтейнер, решили начать линковать с gpg2, а не с gpg. Сам mcabber вообще ничего про это не знает, т.к. завязан только на gpgme:
    $ cd ~/pkgsrc/chat/mcabber
    $ bmake show-depends
    gpgme>=1.3.0nb1:../../security/gpgme
    libotr>=4.0.0nb1:../../chat/libotr
    openssl>=1.0.1c:../../security/openssl
    loudmouth>=1.4.3nb6:../../chat/loudmouth
    glib2>=2.34.0:../../devel/glib2
    libidn>=1.20nb1:../../devel/libidn
    ncursesw>=5.5:../../devel/ncursesw
    desktop-file-utils>=0.10nb1:../../sysutils/desktop-file-utils
    К счастью, в gpgme предусмотрена опция gpgsm, отключение которой по легенде должно переключать зависимость с gpg2 на gpg. Добавляем PKG_DEFAULT_OPTIONS=-inet6 -gpgsm в ~/pkg/etc/mk.conf и проверяем:
    $ cd ~/pkgsrc/security/gpgme
    $ bmake show-options
    Any of the following general options may be selected:
            gpgsm
     
    These options are enabled by default:
            gpgsm
     
    These options are currently enabled:
     
    You can select which build options to use by setting PKG_DEFAULT_OPTIONS
    or PKG_OPTIONS.gpgme.
    $ bmake show-depends
    gnupg>=1.4.2:../../security/gnupg
    pkg_install-info-[0-9]*:../../pkgtools/pkg_install-info
    librfuncs>=1.0.7nb1:../../devel/librfuncs
    libassuan>=2.0.2:../../security/libassuan2
    libgpg-error>=1.10nb1:../../security/libgpg-error
    Итак, теперь gnupg>=1.4.2. Казалось бы, жизнь налаживается, ещё немного — и будет победа. Однако, компиляция (команда bmake) вылетает с ошибкой:
    gpgsm --import ./cert_g10code_test1.der
    bmake: exec(gpgsm) failed (No such file or directory)
    Как всегда, мейнтейнер проверял компилируемость только с дефолтными опциями. При более внимательном рассмотрении логов обнаруживается, что на стадии конфигурирования вылезает предупреждение:
    configure: WARNING: unrecognized options: --without-gpgconf, --without-gpgsm
    В options.mk при этом написано:
    ##
    ## Option to build with gpgsm. This provides SMIME support
    ##
    .if !empty(PKG_OPTIONS:Mgpgsm)
    .  include "../../security/gnupg2/buildlink3.mk"
    CONFIGURE_ARGS+=        --with-gpgsm=${BUILDLINK_PREFIX.gnupg2}/bin/gpgsm
    CONFIGURE_ARGS+=        --with-gpg=${BUILDLINK_PREFIX.gnupg2}/bin/gpg2
    REPLACE_SH+=            tests/gpg/pinentry
    .else
    DEPENDS+=               gnupg>=1.4.2:../../security/gnupg
    CONFIGURE_ARGS+=        --without-gpgconf
    CONFIGURE_ARGS+=        --without-gpgsm
    .endif
    Прервал на стадии кофигурирования, залез с конфигуратор gpgme, проверил. Всё там есть, такие опции должны приниматься. Есть ещё иной вариант — указать их в options.mk как
    CONFIGURE_ARGS+=       --with-gpgconf=no
    CONFIGURE_ARGS+=       --with-gpgsm=no
    Однако, этот вариант тоже не канает. Наконец, раз он фейлится на конкретном тесте, есть возможность отключить его, поэтому добавляю строку:
    CONFIGURE_ARGS+=       --disable-gpgsm-test
    Теперь, наконец-то, gpgme скомпиливается до конца. Однако, поскольку gpgsm так и не удалось отключить, кабальная зависимость от gpg-агента и прочих pinentry всё равно вкомпиливается, пофиг что gpg, а не gpg2.

    Ладно, может хотя бы теперь пассфраза не будет на каждое сообщение запрашиваться? Надежда какая-то есть. Вообще, тут есть глобально, о чём подумать. В Debian ведь тоже всё завязалось на gpg2 после включения зависимости в gpgme... В частности, это всё похабит и для других программ, таких как mutt и т.п. Кто-то решил, что десктоп должен выглядеть именно таким, с pinentry и не иначе. И одной зависимостью такая кабала была включена в массу программ. Ведь жили же десять лет без этой дури, но нет, кто-то решил, что давно пришло время всё сломать и претворить gpg2-страхи из страшилок в интернет-статьях в повседневный быт. Пусть народ потрахается по полной, не зря ж эту дрянь кто-то писал. pulseudio и systemd тоже вот не зря писали, поэтому вчера если это было «вас пока не касается», то сегодня это «извините, но мы решили, что пусть это будет дефолтом в вашей ОС, да».

    Короче, возвращаемся в директорию mcabber, делаем для него bmake и bmake install. Быстро сказка сказывается, да не быстро дело делается, вот что в итоге будет скомпилено и установлено:



    Очень повезло, что ни один из этих гигантских пакетов не вылетел с непонятной ошибкой при компиляции.

  1. Всё скомпилилось, момент истины близок. Чтобы локально установленный mcabber перекрывал системный, вносим в конфиг шелла настройки: начало export PATH пополняем путями /home/$USER/pkg/sbin:/home/$USER/pkg/bin, а также переопределяем MANPATH:
    export MANPATH=/home/$USER/pkg/man:$MANPATH
    Теперь можно самый новейший и честно скомпилированный mcabber 10.0.3 (последняя версия на текущий момент; более свежая, чем в Debian) запустить.

Печальные итоги


mcabber из pkgsrc:

  1. Запрашивает PGP-пассфразу через агент. Плохо, конечно, но морально к этому уже был готов, перекомпиляция gpgme не была вполне успешной. ☹

  1. Не может соединиться с сервером и при этом пишет предельно информативную ошибку «Generic SSL error». На точно таком же конфиге Debian'овского mcabber'а соединение проходит на ура. Конечно, он завязан на только что скомпилированный (из pkgsrc) openssl, так что мало ли что там могло быть, но есть более вероятная гипотеза источника проблем — в ChangeLog написано:
    mcabber (0.10.3)
     
     * [UI] Add option 'iq_time_hide'
     * [UI] Add 'iq_version_hide', 'iq_version_hide_version'
     * Improved handling of damaged history log files
     * Switch to libotr v4 API (Myhailo Danylenko)
     * Add SSL options (Frank Zschockelt)
       These options require a patched Loudmouth library.
       - "ssl_ciphers" to define the allowed ciphers
       - "ssl_ca" to set additional trusted certificates
     * Fix compilation for old loudmouth libraries (Frank Zschockelt)
     * Add 'color_timestamp' to highlight timestamp added by server 
       (Hermitifier)
     * New python based event script using OS X 10.8 notification 
       center (Sharoon Thomas)
     * Handle SIGHUP signal (Dominik George)
     * Misc. bugfixes
    Всякие новые hide-опции — это, безусловно, хорошо, как и детализация расцветки, но важно другое: по-видимому, «patched Loudmouth library» — это не то, что по умолчанию компилится при расручивании зависимостей в pkgsrc. На сайте рекомендуют использовать их loudmouth:

    2012/12/01: New Loudmouth snapshot tarball from our LM git tree available.

    Вряд ли этой рекомендации вняли мейнтейнеры pkgsrc-пакетов при учёте зависимостей.

  1. Ладно, хоть всё и плохо, у нас есть последний козырь, о котором мало кто догадывается. Мы берём вместо обычных jabber-серверов onion'овские, где с превеликим удовольствием можно на SSL положить. Более того, его там лучше не включать, даже если можно. Сказано — сделано, добавляем в mcabberrc:
    set ssl = 0
    set tls = 0
    Победа? А вот и нет. Шах всем и мат: authentication error, хотя точно такой же конфиг на Debian'овском mcabber'е коннектится на ура.

Да, не у всех сказок хороший конец. У этой плохой. П-сы победили. Наверно, я неопытный и глупый пользователь, так и не смог найти подход к софту. Целый день убит зазря, все эксперименты не имели смысла. Приходится принимать соломоново решение: сбрасываем пароль с PGP-ключа, используемого в mcabber, и все проблемы как рукой снимаются ценой появления вопросов к безопасности. И после этого ещё кто-то интересуется, почему я зациклился на pinentry и т.п. штуках. Хочу добавить, что мне известно, что аналогичные проблемы с запросом пассфразы, хоть и не такие фатальные, есть и в других Debian-/Linux-дистрах, многие жалуются и какими-то костылями пытаются разрулить. В лучшем случае всё сводится к «извини, я тупанул с пассфразой, и снова всё потерялось, перешли все сообщения повторно», которое может возникнуть два и более раз подряд.

Это даже не вопросы софта, это исключительно политические вопросы. С чего какой-то мудак решил, что gpg2 и «gpgsm» всем позарез нужно? Почему кто-то за всех решил, с чем будут слинкованы все пакеты по дефолту? Можно ведь найти конкретных людей и конкретные фамилии, которые внесли эти изменения, поднять срач, призвать к ответу, пригрозить санкциями, встретить ночью в подъезде. Почему тысячи людей по всему миру должны плясать под дудку какого-то дурака, у которого зачесались ручки внести изменения в конфигурацию таких важных пакетов? Почему я должен тратить своё жизненное и рабочее время на разруливание всех этих проблем?

Можно, конечно, сказать, что мало ли какие есть джаббер-клиенты, пакет не так важен. Но хороших, которые умеют и OTR и PGP, да ещё и с кучей полезных плюшек и при этом консольных в альтернативе нет ни одного. Т.е. либо сильно поступаемся юзабилити, либо жрём кактус. И джаббер — это один из самых важных пакетов в ОС, фактически основное окно во внешний мир. Ну не ICQ же со скайпом использовать со всеми и вся, в конце концов, и не соцсети. Torchat — тоже не дело, а onionphone не допилен. Некуда податься.

P.S. Максима о том, что обновление софта всегда приводит к тому, что всё рушится и перестаёт работать, подтверждается со 100%-ой вероятностью.
— SATtva (31/01/2015 14:26)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Сразу предупреждаю, прочитал пост по диагонали, но не понимаю, в чём проблема с gpg2 и pinentry? Только в частых запросах пассфразы? Вы пробовали корректно запустить gpg-agent (пример есть в его мане), чтобы он не спаунился заново на каждый чих и нормально кэшировал пароль?
— SATtva (31/01/2015 14:32)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
К слову, если не нравится гуишный pinentry, переменной PINENTRY_USER_DATA="USE_CURSES=1" можно принудительно запускать только консольный вариант.
— Гость (31/01/2015 14:47)   <#>

Фатальная — да.


Руками я его не запускал. Поидее это должен делать джаббер-клиент. Во время работы джаббер-клиента он висит в списке процессов, т.е. запущен. Но мысль интересная, спасибо. Можно попытаться запустить руками и поиграться с конфигами/опциями, вдруг взлетит всё-таки.


Для начала надо добиться, чтоб он вообще работал, хотя бы какой-то. Думаю, тут не влияет, какая программа запускается.
— Гость (31/01/2015 14:52)   <#>

А какой из них безопаснее? Или всё равно? В обоих случаях будет создаваться дополнительное окно для ввода пассфразы и защиты от «X-sniffing attacks» (см. опцию --no-grab)?
— SATtva (31/01/2015 15:44)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092

So here's your problem. ©


При таком автостарте кэширование не работает.


А фиг, она вообще непонятно где работает, может, только в совсем уж свежих версиях pinentry. Ещё есть вариант с DISPLAY="" (точно работает, по её наличию как раз и определяется, запускать ли гуишный вариант или консольный) и с симлинком с pinentry на pinentry-curses (совсем уж дёшево и сердито).


Только в гуишном варианте.
— Гость (31/01/2015 16:29)   <#>

Значит, он безопасней.

Вообще, принудительный запрет grab'а окон заставляет задуматься. Любой троян, запущенный под тем же юзером, тоже может так делать? Никаких же особых прав не надо, так? А заблокировать клавиши переключения в текстовую консоль он тоже может?


Почему?! Это баг или фича? В man gpg-agent написано, что по умолчанию пассфраза кэшируется на 600 секунд.
— SATtva (31/01/2015 16:49)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092

Очевидно, что да.


Вероятно, ограничение, так глубоко не лазил. Для корректной работы gpg и gpg-agent требуется IPC-интерфейс в виде Unix-сокета. Когда пользователь порождает gpg-agent, путь к этому сокету и PID gpg-agent сохраняются в переменных среды, и запускаемый позднее gpg получает к ним доступ. Видимо, если запуск происходит в обратном порядке (gpg порождает gpg-agent), у gpg нет доступа к этой информации. Почему оно так, сказать затрудняюсь.
— Гость (31/01/2015 22:59)   <#>

Похоже, вы правы. По крайней мере, запросы пароля на каждое сообщение при корректном старте исчезают. Более того, сам mcabber более не запрашивает пароль при старте, это делает только pinentry. Правда, непонятно, почему он хотя и спрашивает пароль для подписи статуса, но не кэширует его, т.к. при тут же посланных сообщениях пароль запрашивается снова (хоть и один раз, но всё равно). Может ли быть такое, что при запуске jabber-клиент принудительно инструктирует gpg-agent не кэшировать пассфразу несмотря на его дефолты? Такое впечатление, что запросы пароля на смену статуса и на расшифровку сообщений как-то слабо между собой связаны, хотя чёткого паттерна не видно. При первом старте идёт стабильно 2 запроса: на установку статуса и на расшифровку первого полученного сообщения (если есть). Однако, при некоторых последующих стартах jabber-клиента может быть так, что пароль не запрашивается вообще ни на что, т.к. он уже сидит в памяти агента. Короче, как-то глючно и слабопредсказуемо, но работает.

Обнаружился ещё один глюк: если сделать /disconnect, а потом снова /connect, то происходит предельно странное:
  1. mcabber пытается сгенерировать OTR-ключ, хотя все настройки OTR отключены в конфиге.
  2. mcabber генерирует не свой ключ, а ключ конакта из ростера! Это вообще полнейшая дичь (это видно по имени ключевого файла в логах).
Может быть, есть какое-то нетривиальное инфицирование одного jabber-профиля другим, но я ничего такого в своих конфигах не нашёл.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3