Pidgin + GPG – есть ли плагин для совместной работы?
Работаю в линукс. Пользуюсь Pidgin 2.3, протоколы ICQ и Jabber. Появилась необходимость приватных бесед. Есть ли возможность прицепить GPG к Pidginу? Плагин какой-нибудь? Сам пытался найти, пусто. Есть какой то заменитель со своей реализацией RSA, но это не подходит из-за ограниченности подхода. Кто нибудь сталкивался? Какие предложения могут быть?
Ссылки
[link1] http://www.xmpp.org/extensions/xep-0155.html
[link2] http://www.xmpp.org/extensions/xep-0116.html
[link3] http://www.xmpp.org/extensions/xep-0136.html
[link4] http://www.xmpp.org/extensions/xep-0027.html
[link5] http://www.cypherpunks.ca/otr/otr-wpes.pdf
[link6] https://www.pgpru.com/forum/prakticheskajabezopasnostj/otrmessagingnezapisyvaemajaperepiska
[link7] http://developer.pidgin.im/ticket/288
[link8] http://sourceforge.net/projects/pidgin-gpg/
[link9] http://www.ohloh.net/p/pidgin-gpg
[link10] https://github.com/segler-alex/Pidgin-GPG/wiki
[link11] http://sourceforge.net/projects/pidgin-gpg/files/
[link12] https://www.pgpru.com/comment25960
[link13] https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto
[link14] https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava1/cifrovyepodpisi
[link15] http://ssl.comodo.com/free-ssl-certificate.php
[link16] https://www.pgpru.com/comment66711
[link17] https://secure.comodo.com/products/frontpage?area=SecureEmailCertificate
[link18] https://www.pgpru.com/comment66838
[link19] https://www.pgpru.com/comment15718
Когда pidgin был ещё gaim-ом там была нормальная реализация на основе ключей, после переименования данная возможность была удалена. Как альтернатива есть шифрование через OTR.
В данном случае можно заверить отпечаток ключа OTR своим обычным ключём либо перейти на другой клиент.
Безрадужная перпектива, т.к. нужена поддержка именно GPG. Довольно странно, что убрали. Видимо дорабатывают или что-нибудь. А может есть не официальная поддержка с помощью плагина? Если о переходе на другой клиент, то какой можете посоветовать (под GNOME). Из протоколов нужен только ICQ и Jabber.
Для jabber – psi. icq можно пускать через jabber icq transport, если такой функционал вас устроит...
Интересно, с чем это было связано... удаление...
Про пользование транпорт через джаббер. Являюсь счастливым обладателем 6-ой аси, не уйдет ли номер при пользование таким сервисом :)?
Я не слышал чтоб jabber-сервера воровали аськи... хотя исключать нельзя. Обзаведитесь транспортом на сервере посолиднее... но тогда будете иметь проблемы с коннектом :) Знаете же что icq поставила квоту на число юзеров с одного узла? Так что в этом смысле OTR-плагин предпочтительнее :) Более того, я вообще не вижу существенных преимуществ gpg-шифрования перед otr в джаббер – только преимущества.
s/только преимущества/только недостатки/
А я являюсь счастливым обладателем независимости от ICQ =)
Попробуйте kopete (KDE-шная).
В gpg-шифровании в отличии от otr есть Web of Trust, что является большим преимуществом.
А какие вы видите недостатки gpg-шифрования?
Преимущества GPG:
1) Универсальность OpenPGP ключей, что облегчает их распостранение.
2) Поддержка сети доверия.
3) Возможность отправки оффлайн сообщений, так как не требуется установка сессии.
4) Отсутствие глюков связаных с установкой сессии. (OTR у меня не шифрует несколько первых сообщений, т.к. не всегда "заводиться" сразу)
5) GPG – это устоявшийся стандарт, более провереный и лучше поддерживаемый, нежели OTR. Соответственно доверия больше.
А равно и вашу отслеживаемость.
Основное преимущество OTR – off the record. Этим всё сказано :) представьте, что вы с кем-нибудь общаетесь и передаёте критическую информацию... а потом поссорлись, как дети малые. Ваш собсеседник может доказать что вы действительно писали то что писали.
gpg призвано обеспечить свободу. истиная свобода – это когда вдвоём наедине и никто не слышит. OTR ближе к этому случаю...
Но и OTR не панацея. Чтобы спать свободно а не думать о СТЛА и КК, достаточно расшарить совместный симметричный пароль, переданный по третьему каналу и на всё остальное положить болт.
Также gpg плох тем что потребляет больше траффика в IM-системах и существенно сильнее тупит... асимметричное крипто – ресурсоёмкая операция по сравнению с симметричным и это особенно заметно на слабых машинах, хотя вполне чувствуется и на сильных (у меня 3ггц и вполне чувствую отличие по скорости доставки когда gpg есть и когда нету... видно на глаз разницу).
Лучше к gpg-шифрованию добавить согласование ключа и оставить выбор между двумя режимами, чем просто удалить данную возможность.
Иногда необходима просто приватность, без возможности отказа.
это... а вы собственно в курсе, что:
1) otr использует gnupg;
2) исходники открытые, если есть сомнения или желание, то можно проверить и отредактировать;
3) всё больше клиентов приобретают плагины включающие поддержку otr;
4) разрабатываются и исследуются соответствующие xep-0155[link1], xep-0116[link2], xep-0136[link3] реализующие функционал otr на основе xmpp-протокола.
И на счет шифрования в xmpp-клиентах *icq*-сообщений передающихся через транспорт, вы хотябы проверили, возможно ли такое? Зашифровать-то зашифрует, но вот сможет ли асечник их потом расшифровать?
Плюсы GPG:
1. Общаясь по рабочим вопросам бывает сложно убедить использовать признанный стандарт OpenPGP, а если начать говорить о чем-то еще, просто плюнут :)
2. Иногда важно подтвердить, что сообщение написал именно ты, и именно ты его получил. Поэтому и ПГП.
Честно говоря otr не пробовал. Надо будет испытать, но душа лежит больше к ГПГ.
Вы хоть почитали бы, хотяб на этом форуме, что это вообще такое...
Как раз otr именно это и гарантирует, что во время сеанса переписки вы общаетесь с автором приходящих к вам сообщений. В отличии от простого шифрования и подписывания по xep-0027[link4] которое
Учите матчасть, и только потом уж сравнивайте.
Проблема не в низкой скорости шифрования, а в том что для шифрования каждого сообщения запускается новый процесс gpg.exe. Виновата реализация GnuPG plugin. Я думаю как-нибудь сделать реализацию плугина для миранды который будет сам реализовывать крипто.
Раньше юзал OTR на миранде. Потом задолбали глюки и перешел обратно на GPG.
Если бы этот OTR нормально работал, а не тупил при установлении сессии, если бы в нем постоянно не менялись сами собой ключи, если бы была возможность установки сессии и использованием OpenPGP ключей, тогда бы его можно было юзать.
OTR разрабатывали люди со знанием дела, можете быть спокойны. Вообще спор довольно странный, типа, что лучше, кроссовки Найк или итальянская паста? OTR и GPG преследуют отчасти разные цели (вместе обеспечивая конфиденциальность): для GPG первостепенна аутентичность, для OTR — "незаписываемость" во всех смыслах слова. Лично для меня важны оба свойства, всё зависит от предмета обсуждения и/или моего собеседника.
Доказать где, в суде что-ли? Я Вас умоляю! "Ничего подобного я вообще не писал, а что Вы там говорите про электронную подпись не знаю, её компьютер вычислял, который у меня — просто рассадник вирусов". Никогда не приравнивайте электронную подпись к собственноручной, если Вы с контрагентом не имеете на сей счёт формального договорного соглашения (тот факт, что термин "электронная подпись" включает слово "подпись" — историческая ошибка, именно так и смотрите на это).
В общем случае, это плохая мысль. Шифрование нельзя использовать для обеспечения контроля целостности данных. Есть решения на основе симметричных ключей, но не путём простого шифрования (если только не в специализированном режиме): OTR использует имитовставку, GPG — MDC (но не всегда).
Nikita Borisov, Ian Goldberg, Eric Brewer "Off-the-Record Communication, or, Why Not To Use PGP"[link5]
Нет. Вы понимаете, что SSL потому и быстрый, что программа напрямую использует криптобиблиотеку а не запускает каждый раз какую-то прогу типа gpg? Хорошая реализация должна опираться на использование стандартной, проверенной криптобиблиотеки, чтобы снизить накладные расходы при исполнении...
При общении посредством какой-либо IM-системы? Не могу привести жизненный пример.
Если я хочу что-то явно утвердить, могу явно подписать и передать собеседнику... И необходимость в этом возникает нечасто...
Естественно, все otr-системы с icq требуют поддержку плагина соответствующего сорта на стороне получателя.
Может быть в ещё убедите сделать что-то аналогичное под UNIX авторa mcabber?
Это в джаббере или в icq? Миранда в качестве джаббер-клиента... это... ну я вас понял бы если б не было альтернатив только... в общем не это её сильная сторона.
Sicuramente, la pasta italiana e` piu` buona!
Да нет, достаточно даже в каком-то сообществе :-)
Руткитов и бэкдоров. Угу. Под UNIX :)))
И всё же логи имеют доказательную силу :)
А есть жЫвЫе реализацЫи?
Ну, показать пальцем и уличить в обмане — это другое дело. Кто-то и не пойдёт на обман, не желая жертвовать хорошо распространённым и связанным (в контексте Сети доверия) открытым ключом. Своего рода репутационная система.
Так ведь первым делом отмазки начнутся с того, что всё это хозяйство на Виндоусе крутилось!
Логи провайдеров, имеющие доказательную силу, генерятся биллинговыми системами, обладающими сертификатами Минсвязи и Гостехкомиссии. Создание дружественных аудиту систем — сама по себе нетривиальная задача.
Ну так тот самый OTR[link6].
Само собой! Да и кому вообще может нравиться Найк? :-)
Альтернатив нет. GPG еще поддерживается QIP, sim и gajim. QIP closed source, а остальные два настолько уе..щьны, что это юзать невозможно.
Я имиел в виду реализации на основе симметричного крипто полностью устойчивые к взлому посредством КК.
Это Gajim или QIP у..бищный? Или что? А только установил гажим – так вроде ниче.
После гибкости и удобства миранды все другие мессенжеры кажутся полным отстоем. Разве что QIP кое как с ней можно сравнивать. Единственный минус миранды – повышеная глючность, но эту проблему я вроде решил в своей сборке.
Да миранда хороша, вот только версии под линукс нет. А виндовс я не использую.
ребят вы от темы отошли
Три года назад, ага.
Не густо:
OpenPGP in Jabber[link7]
pidgin-gpg-0.1-beta[link8]
pidgin-gpg[link9]
Свежее, open source, Linux/Windows
Кто-нибудь пробовал, тестировал?
Пардонте за ошибочную ссылку
GPG/OpenPGP Plugin for Pidgin (XEP-0027[link10])
Свежее, open source, Linux/Windows
Кто-нибудь пробовал, тестировал?
Да уж, свежак[link11].
Вы невнимательно читаете. Это ошибочная ссылка.
Вот свежее: GPG/OpenPGP Plugin for Pidgin (XEP-0027[link10])
Ага, любопытно. Однако Гость (14/03/2011 18:41) давал ссылку именно на тот свежачёк.
Попробовал.
В Ubuntu 9.10/10.04 все нормально ставится из указанного репозитория.
В Ubuntu 9.04 попытка сборки не удалась.
В Windows XP для Pidgin 2.7.11 плагин инсталлируется, но не подключается.
Для ряда клиентов XMPP (PSI, Gajim, Kopete и т.д.) есть поддержка OpenPGP, что позволяет осуществлять шифрование передаваемых сообщений. Как при этом обстоит дело с аутентификацией отправляемых сообщений, средства OpenPGP при этом задействуются или ключи используются только для шифрования?
Несколько раз перечитал вопрос. Никак не пойму что надо то? Сообщения шифруются. Что не дает покоя то?
Видимо, имеется ввиду установление идентичности собеседника в начале общения. В OTR это типа есть. Реально же по ключу надёжнее.
Плохо, очень плохо[link12].
Вроде бы оно зависит от клиента, тот раз на 100% не разобрались. У меня осталось впечатление, что, как правило, отсылаемые сообщения только шифруются, а рассылка статусов только подписывается. Тем не менее, например, плагин к Miranda и tkabber рассылку статусов не подписывали, хотя сообщения шифровали.
Шифруются ≠ подписываются. Матчасть[link13] надо бы знать.
К слову, то, что они в OTR подписываются, тоже никто не утверждал.
В этой теме усмотрел, что для Pidgin есть GPG-плагин. Если кто в работе использовал интересны отзывы, нормальный плагин?
Не использовал, но слышал, что это Pidgin — мультипротокольное говно. Нормальные джаббер-клиенты с гуем — Gajim и Psi, для особо одарённых и желающих потрахаться с плагинами есть tkabber. Консольный клиент практически единственный, это mcabber. Выбор небогат. Советую не тратить своё драгоценное время на клиенты, где поддержка PGP через костыли, а брать клиент, где оно работает искоробки. Как минимум в трёх клиентах это так — в Gajim, Psi и mcabber.
Вы об этом?[link14] В случае, если сообщение зашифровано, значение подписи, имхо, сводится к минимуму.
Не сводится. Это даёт человеку посередине возможность вставлять произвольные сообщения.
Я сейчас бегло смотрю xep-0027, насколько я понимаю, ничто не мешает подписывать зашифрованные сообщения (combined), а при расшифровке смотреть ещё и на статус подписи.
Шифрование и подпись сообщения умел делать и старый Бат со встроенным модулем.
я на самом деле не понимаю, что это дает. есть тема переписки и тут появляется сообщение, от которого даже нет ключа. и что с этим делать? кража секретных ключей? ну тогда вообще речь не об этом и не здесь. подмена ключей при митм? тоже не та ситуация и не о том.
Ключ от него есть. Открытый ключ всем известен.
Может быть как-нибудь так:
Если он опубликован или его можно извлечь из перехваченного сообщения? Ну в общем-то убедительно.
Отправил не закончив мысль (( пардон.
Убедительно в том случае, если "посередине" могут читать переписку. НО как они это могут сделать без секретных ключей?
Злоумышленник может послать шифрованное письмо, как и любой желающий, примерно зная о чём общаются собеседники, подделывая обратный адрес и выдав себя за другого. Без подписи наугад может прокатить какая-нибудь провокация: например просьба придти на встречу; утверждение, что якобы надо отправлять почту на новый адрес для связи и шифровать новым ключом и пр.
Подписи связывают подключи внутри основного ключа, что даёт уверенность, что связку меняет только владелец. Подписи транслируют доверие с одних ключей на другие. Аутентификация — это фундаментальный механизм.
Можно создать, например SSL сертификат[link15] и прикрутить в почтовике к адресу отправителя и своему. Это даст автоматическую проверку подлинности адреса отправителя, а уже в сообщение класть зашифрованный текст. Как такая схема? Создать сертификат можно не только по приведенной ссылке, но и в программах на ПК пользователя.
По всей видимости, ваша проблема в том, что вы не понимаете, что обычно считается, что открытый ключ известен всем. У меня может быть 10 адресатов, и каждый из них использует мой открытый ключ. Если мне послал сообщение один адресат или другой, я не могу их различить техническими средствами, каждый потенциально может выдать себя за другого.
Вы можете отойти от стандартной модели PGP и считать, что ваш открытый PGP-ключ секретен, и он разный для разных адресатов. В этом случае — да, подмену сделать будет не так просто, но и тут не всё идеально: противник, имея какие-либо догадки о содержимом сообщений, может переотправлять их вам, выдавая себя за адресата. Если какое-то сообщение содержит «да», и противник вам отправит его в нужный момент, вы получите ложное сообщение и ничего не сможете распознать. Проверка целостности и отсутствия перепосылок должна быть частью протокола более высокого уровня, но даже на низком уровне проставляется метка времени при использовании PGP-подписи. Глядя на неё, можно делать выводы о том, была ли переотправка сообщения. Ещё противник может перехватить какие-то сообщения так, что до адресата они не дойдут, а потом вбросить их в канал спустя долгое время. Короче, есть много тонкостей. Кстати, при шифровании без подписи метка времени проставляется? Уже не помню.
Лучше, чем ничего, но хуже PGP-подписей с шифрованием, поскольку требуется безоговорочное доверие третьей стороне — mail-серверу. По умолчанию доверие в End2End-шифровании только к концевым точкам: конечному отправителю и конечному получателю. Если они не скомпрометированы, то всё работает, а у вас потребуется доверие ещё какой-то стороне.
Так и есть. Понятно что неудобно, но есть еще круче схема – ключ на каждый день недели для каждого адресата сроком на 2 недели.
Я понял о чем Вы, но заставить всех корреспондентов еще и подписывать ((( Тут шифрование сообщений сложно добиться. Про консоль вообще молчу.
Это похоже на мелкое пакастничество. Понятно же, что если сообщение не дошло и на него не получен ответ, это инициирует повторный запрос.
Смешивать две модели аутентификации, одну на OpenPGP, другую на PKI? Причём доверие в PKI зависит от того, что поставит удостоверяющий центр, потенциальное мошенничество которого стороны, скорее всего, каждый раз проверять не будут. Если вообще этим хоть раз озадачатся.
Необязательно. Представьте, что идёт онлайновое общение в IM, каждую минуту посылается куча сообщений. Если какие-то из них будут искажены или попросту не дойдут, вы даже не заметите этого.
Подпись часто сопуствует шифрованию.
- Зашифровать, не подписывая: gpg -e filename
- Зашифровать с подписью (считаем, что приватный ключ у вас один): gpg -es filename
Отличие лишь в одной букве. Если хочется, чтоб шифртекст был в читабельном формате (но он так весить будет больше), добавляете опцию a: пишете -ea или -esaВ винде, правда, надо писать gpg.exe вместо gpg вроде.
По умолчанию, вроде, во многих интерфейсах и стандартных конфигах шифрование идёт с подписью или её по-крайней мере предлагается сделать.
Точно сказать не могу, т.к. использую свою шпаргалку с полным набором опций для нужных команд.
подпись идет отдельной операцией, хотя в Том же TheBat со встроенным модулем можно эту операцию совместить. Однако в нем старый pgp.
Сертификат можно создать самому.
Всё-таки лучше в интерфейсах почтовиков автоматизировать шифрование с подписью, чем совмещать два разных протокола. Наверняка такая настройка есть. И будет уверенность в том, что отправитель — владелец ключа и метка времени при подписи ставится. Т.е. такую метку может подделать только сам отправитель, а не прослушивающая сторона, которая будет пытаться весьти игру с переотправкой.
Кстати, ещё такой совет: не давайте слишком простых, односложных ответов. Кто-то может спросить в шифрованной переписке: "Ответь, да или нет?" и получить ответ "нет". Если шифрующая сторона по размеру сообщения и контексту общения догадается об ответе, она может пытаться вбросить это сообщение повторно в качестве ответа на другой вопрос. Также это касается таких простых вещей, как время, координаты, денежные суммы и пр.
Имеется ввиду взять такой порядок общения за правило? Чтобы односложные ответы диссонировали?
Нумеровать, обращать внимание на время подписи, цитировать предыдущий вопрос, пересправшивать важное.
Э. Сноуден в переписке с журналистами упоминал, что АНБ проводит семантический анализ шифртекста PGP-сообщений, вероятно по таким простейшим признакам, как размер. Правда, в его случае, это было скорее для определения утечки документа по характерному приблизительному размеру шифртекста.
Видимо не совсем понимаю основы, потому возникает вопрос. Предполагал, что при использовании OTR сообщения im переписки не могут быть прочитаны третьей стороной, и подделаны. Но получается это не так, можно mitmom влезать в зашифрованный диалог и подделывать сообщения? Или подразумувается что сами ключи переписки необходимо передавать по другим каналам, или pgp и тогда их просто ну будут знать, и влезть в диалог не смогут, правильно?
Речь шла об OpenPGP, затем стали говорить о сертификатах, надо полагать для стандарта S/MIME. А в OTR используется симметричная аутентификация вместо подписей, поскольку канал реального времени.
Да там пароль используется для сессии.
Всё смешалось. :-(
Это мимолётом обсуждавшийся отход от стандартой модели PGP. Он лишь частично помогает, но не реашет проблему. Не важно, знает атакующий ваши ключи или нет, если он сидит на канале, кто ему запретит посылать повторно уже вами посланные сообщения? Кто ему запретит их перехватывать, не доставляя адресату?
*Правда, стоит понимать, что сам адресат, владеющий своим приватным ключом, может как угодно подделывать метку времени, от этого защититься нельзя.
Запретить никто не сможет, такой вопрос криптография не решает. А вот обнаруживать потерю промежуточных сообщений, например, путём вставки счётчика в каждое сообщение, вполне можно. Это и от повторной пересылки также защищает. Вообще, всё это нужно сделать для XMPP в виде нового XEP, нынешний XEP-0027 – наколенная поделка.
Вообще, поднятый вопрос глубокий. Так сказать, до публики начинает доходить то, что unknown писал ещё 5 лет назад: есть криптопримитивы и есть протоколы, причём из безопасности криптопримитивов безопасность протоколов не следует. Можно взять кучу безопасных кирпичиков, соединить их бездумно и получить
ущербныйнебезопасный протокол. Когда хочется, чтобы в канале связи было «всё включено», PGP играет роль (макро)криптопримитива, а вот как на основе его создать протокол, где всё было бы безопасно (защита от вбросов, переотправок, от потерянных сообщений и т.д.) — это уже другой вопрос.Может, неудачно выразился, хотя стараюсь быть предельно внятным, но да, именно это и имелось в виду: обнаруживать атаку вовремя.
Почтовые сообщения нумеруются, причем поле Тема не должно иметь намека о теме переписки, а в IM каждое полученное сообщение подтверждается не односложными предложениями-ответами.
1. Есть ли необходимость сверять отпечатки, если обмен ключами производился из рук в руки или создан одной стороной для обеих сторон?
2. Как сверить отпечаток в OTR, если там используется парольная фраза?
Вот тут вопрос. Попробовал я подписать сообщение в Gpg4Usb, так для этого потребовался мой приватный ключ, а не открытый ключ получателя. Собственно сам вопрос:
– Как получатель произведет проверку подписи?
– Если сообщение подписывается не открытым ключом, сможет ли противник вбрасывать ложные сообщения?
И чем тут примитивная нумерация поможет?
Нет.
Если после создания вы вынуждены передать ключ по недоверенному каналу, как мы можете быть уверенны в том, что ваше сообщение не было подменено? В этом случае сверять отпечатки нужно, да.
Не во всех реализациях так. Подозреваю, что вы говорите о том случае, когда обе стороны кладут каждый себе один и тот же «предрасшаренный» секрет. Если они убедились в его идентичности, то ничего дополнительно подтверждать не надо. Убедиться в его идентичности можно, если абоненты обменяются копиями этого секрета, переданными друг другу с помощью PGP-зашифрованных и подписанных сообщений.
Если у получателя уже есть ваш публичный ключ, то командой gpg -d message (в выводе будет писаться в т.ч. и о наличии подписи) или gpg --verify message.
Сообщение всегда подписывается приватным ключом, иначе бы понятие подписи не имело смысла: любой из ваших абонентов, имеющий ваш публичный ключ, мог бы подписать ваше сообщение и выдать себя за вас. На уровне реализованных стандартов подписать сообщение открытым ключом невозможно.
Наверно тем, что сообщения не потеряны. Вот так вот примитивно, но действено.
Исходя из написанного, противник не может вбросить заведомо ложную инфу в случае, если в переписке принято подписывать сообщения.
Прошу прощение. Здесь SSL сертификат[link16] неверно указана ссылка на страницу.
Правильно считать ЭТУ[link17] для генерации сертификата.
Так вы предлагаете номера проставлять в том тексте, который будет шифроваться? Ну так это другое. The Bat эти номера не увидит, нужно будет писать собственные обвязки вокруг мейлера, чтобы эти номера автоматически выуживались из содержимого писем и как-то отображались в интерфейсе (ну, либо каждый раз анализировать их вручную).
Может. Никто ему не запретит перепослать сообщение в любой момент. Если перепосылка будет совершена быстро, в рамках дозволенного времени, вы даже не заметите, что что-то не так по метке времени. Всегда могут быть ситуации, когда это сработает, потому что невозможно вычислить точное время, которое должно пройти между подписью сообщения и его доставкой по сети получателю.
Да простит меня SATtva, сейчас покажу на практие, что имелось в виду, следующим сообщением (а то до кого-то упорно не доходит):
Ладно, всем добрых снов, буду к завтрашнему вечеру.
Говорить о надёжном протоколе шифрования, наверное, не слишком осмысленно, если вспомнить про такой факт, как отсутствие в XMPP куда более элементарной вещи: подтверждения доставки сообщений. При проблемах со связью джаббер часто теряет сообщения, и отправитель никогда не знает заранее, что дошло до адресата, а что нет, потому, что случись, каждый раз приходится это уточнять, пересылая друг другу логи.
XEP-0022, XEP-0085, XEP-0184 описывают это. 22 – устаревший, 85 и 184 – актуальный. И судя по внешнему поведению некоторых клиентов, что-то из этого даже используется.
Видимо, не во всех клиентах это есть. Лично я не сталкивался с таким ни разу. Может, не те клиенты использую.
На всякий случай обращаю внимание на дату подписи этого комментария[link18]. Используя мой старый[link19] комментарий, гость хотел показать, что атакующий может довольно легко ввести корреспондентов в заблуждение, если они недостаточно внимательны либо если от невнимательности их не защищает сам протокол.
Стоит отметить, что тот ваш старый комментарий — тоже не ваш (12/06/2007 — комментарий, 09/06/2007 — подпись), так что имеем воровство уже украденной подписи. :-)
Ребята, не знал где запостить. Нашёл эту тему про пиджин.
У меня винда хр+пиджин 2.10.6
Пиджин хранит историю соообщений на диске ц. Как изменить диру в том место куда мне надо? Т.к. в самом пиджине я там не нашёл этого? (
В юниксах можно было бы сделать так: найти диру, куда он сохраняет историю, удалить её, а вместо неё создать симлинк с таким же именем, указывающий на диру в другом месте. В винде тоже есть target-ссылки, но не знаю, заработают ли они в вашем случае при таком трюке.
Не знаю, я за вами не следил, когда вы искали.