при расшифровке текста каждый символ CR (конец абзаца) удваивается (Thunderbird/Enigmail/GnuPG)

Использую связку Thunderbird 7.1/Enigmail/GnuPG. При ответе на любое зашифрованное сообщение в цитируемом тексте после каждой строки зачем-то добавляется еще один дополнительный символ CR (конец абзаца), то есть, после каждой строки текста добавляется одна пустая строка.

Причем интересно, что сам Thunderbird в окне составления ответного сообщения эти лишние CR (пустые строки) почему-то не отображает, то есть, сам я при составлении ответа цитируемый текст корректно. Чтобы увидеть лишние CR, надо скопировать текст из TB в адекватный текстовый редактор.
Но когда я отошлю свой ответ вместе с этим входящим сообщением, особенно если у адресата стоит не Thunerbird, а другой почтовый клиент, то он увидит предыдущую цитируемую переписку со всеми лишними CR – и отошлет ее мне обратно, а потом при расшифровке каждый CR опять удвоится, и так до полной потери читабельности.

Проверял несколько раз, проблема именно в том, как сообщение расшифровывается в Thunderbird 7.1/Enigmail/GnuPG. Если просто скопировать текст входящего зашифрованного сообщения и расшифровать в PGP Desktop, то никаких лишних CR не добавляется. То есть, само сообщение нормальное, а глючит механизм расшифровки.

Комментарии

—	*Гость* (11/12/2011 05:37) <#>

Символ конца строки в DOS/Windows и в UNIX — разный.

—	leopoldus (11/12/2011 12:47, исправлен 11/12/2011 13:11) профиль/связь <#> комментариев: 6 документов: 4 редакций: 0

И что из этого следует?? Если это намек, то моих мозгов, к сожалению, не хватает, чтобы правильно его истолковать.

На всякий случай уточню, что у меня – Windows XP, соответственно, используются версии Thunderbird и GnuPG для Windows. Кстати, у отправителя, насколько я знаю, тоже Windows.

—	*Гость* (11/12/2011 17:38) <#>

Если у всех Windows, то не знаю.

—	leopoldus (11/12/2011 20:02) профиль/связь <#> комментариев: 6 документов: 4 редакций: 0

Кстати, "порча" входящего сообщения, возможно, происходит не прямо при расшифовке, а при вствке расшифрованного текста как цитаты в составляемый мной ответ. Если, например, расшифровать входящее сообщение в отдельном окне просмотра сообщения (или панели предпросмотра, что в техническом аспекте то же самое), то никаких лишних CR не добавляется.

Напрашивается предположение, что это баг самого Thunderbird, никак не связанный с шифрованием и GnuPG. Однако это все же не так: ведь при ответе с цитированием на обычные незашифрованные сообщения не добавляется лишних CR.

P.S.
Можно каждый раз расшифровывать входящие сообщения в отдельном окне, копировать оттуда в буфер обмена, потом вызывать форму ответа и вручную вставлять туда ранее расшифрованный текст в качестве цитаты... Но удобным такой способ не назовешь.

—	SATtva (12/12/2011 08:00) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Напрашивается предположение, что это баг самого Thunderbird, никак не связанный с шифрованием и GnuPG. Однако это все же не так: ведь при ответе с цитированием на обычные незашифрованные сообщения не добавляется лишних CR.

Я бы сказал, что это баг Enigmail при работе с данной версией Thunderbird. Для начала обновитесь до актуальных версий (TB, скажем, уже есть 8.0) и если проблема сохранится, то отправьте багрепорт разработчикам Enigmail.

—	leopoldus (12/12/2011 13:01, исправлен 12/12/2011 13:02) профиль/связь <#> комментариев: 6 документов: 4 редакций: 0

Я бы сказал, что это баг Enigmail при работе с данной версией Thunderbird

А у других этот баг тоже проявляется или только у меня?

Для начала обновитесь до актуальных версий (TB, скажем, уже есть 8.0)

AFAIK Между последними версиями Thunderbird нет существенной разницы в механизмах обработки почты.
А Enigmail у меня как раз самая последняя, так как плагины обновляются автоматически.

—	SATtva (12/12/2011 18:44) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

А у других этот баг тоже проявляется или только у меня?

По крайней мере, у меня на Линуксе в TB 8.0 с Enigmail 1.3.3 такой проблемы нет.

—	sentaus (18/12/2011 17:15) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

По крайней мере, у меня на Линуксе в TB 8.0 с Enigmail 1.3.3 такой проблемы нет.

В Enigmail явно что-то в обработке концов строк поломано. Например, RFC-3156 требует, чтобы подписи в PGP/MIME генерировались по тексту, в котором используются cr-lf концы строк, т.е нужно делать преобразование, если концы строк юниксовые. Ну и при проверке, соответственно, тоже такое преобразование должно делаться. По крайней мере нестабильная ветка 1.4 такой проверки не делает, и в результате подписи от клиентов, следующих RFC-3156, получаются неверными. Возможно, эта проблема как-то связана с обсуждаемой здесь.

Ваша оценка документа [показать результаты]