Zammad: ПГП

+1 за поддержку S/MIME

Хорошо, я изменил название. Лучше всего, конечно, если бы он предлагал обе вещи.

Я был бы признателен за возможность отправлять и получать зашифрованные сообщения X.509.

ДА, было бы очень приятно иметь возможность отправлять и получать подписанные или зашифрованные сообщения X.509.

Таким образом, зашифрованные письма X.509 — это письма S/MIME. Лично мне больше хотелось бы PGP (еще и потому, что она более распространена), но этот вопрос касается обеих систем. 😃

Я бы добавил зашифрованные уведомления в список пожеланий, поэтому пользователи должны иметь возможность добавлять открытый ключ в свой профиль.

К вашему сведению: для redmine существует хороший плагин с такой функциональностью: https://github.com/C3S/redmine_openpgp .

Похоже, что эта жемчужина на самом деле не поддерживается (последняя фиксация), но есть множество других . Лично я бы сказал, что этот драгоценный камень имеет самую последнюю фиксацию.

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

+1.
Мы работаем с сообществом IT SEC и получаем тонны писем, зашифрованных PGP, которые мы не можем открыть в Zammad, поэтому нам приходится экспортировать и расшифровывать, это адский рабочий процесс. +1 за поддержку PGP и, возможно, S/MIME Mail в Zammad :)

В настоящее время шифрование электронной почты является обязательным. Общий регламент по защите данных (GDPR) требует конфиденциальности по умолчанию и по умолчанию, а также в соответствии с современным уровнем развития техники.

Технически это может быть легко решено путем интеграции механизма p≡p (довольно простая конфиденциальность).

+1
Мы часто получаем зашифрованные письма. Экспортировать и вручную расшифровывать зашифрованные тикеты мучительно, а потом мы даже не можем ответить на тикеты через тикет-систему.

+1
Без PGP/GPG я не могу перейти с OTRS на Zammad. У меня много зашифрованных билетов с помощью gnupg в моем старом OTRS.

+1

Мы хотели бы, чтобы GnuPG подписывал все исходящие электронные письма с билетами после очень уродливого случая подделки нашей электронной почты, чтобы ограбить наших клиентов.

Возможно , PeP можно было бы интегрировать, так как это простое и удобное решение для шифрования PGP.

Я также думаю, что было бы отличной возможностью отправлять подписанные электронные письма. Это дало бы получателю некоторую степень уверенности в том, что адрес настоящий и ему можно доверять.

Следующим шагом будет полное шифрование сообщения.

@martini @monotek мы думаем о том, чтобы заняться частью GPG своими силами. Есть ли какие-либо ограничения на слияние, если мы это сделаем? любые функции, которые вы хотели бы видеть или требуют?

Привет @luto - звучит хорошо! Вещи, которые необходимы для слияния:

• Тесты, желательно RSpec
• Документация
• Документация API кода
• Код QAd через нашу конфигурацию rubocop и coffeelint

Мы уже рассмотрели некоторые драгоценные камни Ruby, которые предоставляют API для бинарного файла командной строки gpg. Насколько я помню, ни один из них не выглядел многообещающе. Убедитесь, что вы полагаетесь только на поддерживаемые/качественные зависимости, так как это критическая точка.
Возможна индивидуальная реализация, но не забывайте о расширяемости и обслуживании. Не помещайте всю логику в модуль, а создайте для нее класс lib. Соблюдайте принцип единой ответственности.

Функционал должен включать все варианты подписи, проверки и шифрования/расшифровки отправки и получения писем 🤓
Обработка входящих сообщений должна выполняться как можно раньше, чтобы контент был доступен в других компонентах.
Обработка исходящих сообщений должна выполняться как можно позже, чтобы иметь возможность доступа к содержимому в других компонентах.

Должен быть приятный интерфейс администратора для управления открытыми и закрытыми ключами.

Не стесняйтесь обращаться к нам по адресу [email protected] , чтобы задать любые вопросы, которые у вас есть, и получить нашу поддержку по этому вопросу. Мы очень рады получить ваши 💪 Давайте сделаем это по-заммадски 🏎

У нас также появился первый клиент, который требует такого общения, поэтому я тоже голосую за него. Есть уже прогресс? Я также хотел бы помочь протестировать бета-версию.

@martinseener afaik, это не входит в дорожную карту команды Zammad. В настоящее время мы планируем реализовать это самостоятельно. Если вы хотите внести свой вклад, чтобы мы могли сделать это быстрее, а вы могли обслуживать своих клиентов, не стесняйтесь обращаться по адресу электронной почты в моем профиле на github.

@thorsteneckel В настоящее время я создаю прототип реализации для получения почты, состоящей из двух частей:

1. расшифровать почту в Postmaster::PreFilter : установить расшифрованное сообщение как содержимое; выбросить оригинал; хранить используемый ключ расшифровки в метаданных
2. в Postmaster::PostFilter создайте объект GpgCryptoInfo , присоедините его к Article ; постоянно хранить такую ​​информацию, как используемый ключ расшифровки и статус подписи

Пара вопросов:

• как вы думаете, это должно быть реализовано с использованием этих API фильтров? Или это должно быть жестко закодировано в Channel::EmailParser ?
• есть ли подписчики Postmaster::PreFilter , которым нужен доступ к содержимому расшифрованных сообщений? В этом случае необходима жестко закодированная реализация или Postmaster::EarlyPreFilter .
• есть ли какая-либо информация, кроме используемого ключа для шифрования/дешифрования/подписи/проверки, а также статус подписи полученной почты, которую вы хотели бы сохранить на постоянной основе?

Кроме того, общий вопрос: EmailParser или фильтры кажутся идеальным местом для _расшифровки_ почты; можете ли вы придумать «идеальное» место для их шифрования?

Я надеюсь, что этот выпуск — правильное место, чтобы задавать вопросы о реализации. Если нет, пожалуйста, укажите мне другой, желательно общедоступный, один :) Спасибо!

Привет @luto - сейчас я записываю свои мысли по этому поводу. Так как это довольно большая и важная тема, она требует некоторого времени. Постараюсь успеть к концу недели. Спасибо за понимание.

Небольшое обновление: фильтры Postmaster::PreFilter заказаны. В настоящее время я разместил свой сразу после IdentifySender , поэтому я могу выяснить, какие ключи gpg попробовать. Зная это, фильтры кажутся мне подходящим местом для расшифровки.

@thorsteneckel Спасибо, что нашли время! С нетерпением жду вашей записи. :)

Привет @luto , рад это слышать! Мне нравится иметь координацию в этом вопросе, как вы предложили. Таким образом, это будет прозрачно, и мы сможем повторно использовать общую информацию для технической документации. Вы можете обратиться к этой проблеме в своей рабочей ветке вашего форка, и она будет указана здесь. Пожалуйста, создайте запрос на слияние после внесения изменений. А пока я проверю вашу ветку и увижу изменения.
Функционал S/MIME следует вынести в отдельную задачу, так как сейчас мы его реализовывать не будем.

Что касается ваших вопросов: вы полностью на правильном пути. Я кое-что запишу и отвечу на ваши вопросы по дороге.

Общее развитие

По нашему опыту, разработка через тестирование (с RSpec) лучше всего подходит для такого рода задач. Как вы к этому подойдете, зависит от вас, но нам определенно понадобится комплексный набор тестов для функциональности. Поэтому я предоставлю вам помощника RSpec, который облегчит тестирование и поддержит вас на пути, насколько это возможно. В ближайшие дни добавлю в ветку develop . Вам следует использовать эту ветку в качестве базы, так как она также является и нашей рабочей веткой. В будущем он будет объединен с основным и заменит стабильный.

Почтмейстер:: Префильтр

Postmaster::PreFilter s - правильное место. Вы можете влиять на время выполнения префиксом числа в имени регистрации фильтра . Меньшие числа будут выполнены раньше .
Для уже инициализированных систем также необходима миграция, добавляющая настройку .
Я бы предложил имя что-то вроде app/models/channel/filter/decrypt.rb , но, в конце концов, решать вам.

После завершения регистрации Zammad будет выполнять фильтрацию для каждой входящей почты.

Класс сообщения PGP

Поскольку на данный момент мы реализуем только PGP, мы должны быть уверены, что не создадим препятствий для добавления S/MIME позже. Кроме того, в будущем может потребоваться поддержка PGP по другим каналам, кроме электронной почты. Имея это в виду, мы гарантируем, что серверную часть и API, которые мы разрабатываем, будет легко тестировать и интегрировать. По моему предложению (открыто для обсуждения):

В файле lib/pgp_message.rb должен быть класс PgpMessage #$. Этот класс принимает один обязательный аргумент, который будет (возможно) зашифрованной строкой сообщения/почтовым содержимым. Пример:

instance = PgpMessage.new(email_content)

Экземпляр должен предоставлять следующий интерфейс:

• #подписал?
• #verified?(signature) # подпись необязательна и может быть внешней подписью, например, из вложения
• #signature_error
• #зашифровано?
• #расшифруемый?
• #расшифровано
• #ключ
• #Ошибка расшифровки
• #зашифровать( публичный_ключ(и) )
• #подписать

PGP-интерфейс

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

Интеграция PgpMessage в Postmaster::PreFilter для расшифровки

Затем класс PgpMessage можно использовать в Postmaster::PreFilter для инициализации экземпляра и проверки релевантности сообщения. Если это сообщение, зашифрованное PGP, мы можем использовать другие методы для извлечения необходимых нам данных и перезаписать содержимое для body и attachments в заданном хеше mail .
Кроме того, мы должны хранить некоторую метаинформацию (как вы уже сказали) в статье, которая будет создана путем установки заголовка x-zammad-article-preferences :

mail[:'x-zammad-article-preferences']['decryption_key'] = instance.key
...

Я думаю, что следующих метаданных должно быть достаточно:

• decryption_key <- ключ
• decryption_error <- decryption_error (в случае существования)
• зашифрованное_сообщение <- почта['тело']
• подпись_статус <- проверено?
• подпись_ошибка <- подпись_ошибка (в случае существования)

поддерживаемые варианты расшифровываемых сообщений

Класс PgpMessage должен иметь возможность обрабатывать (по крайней мере?) следующие комбинации и варианты входящих сообщений PGP:

• зашифрованный
• подписал
• зашифровано + подписано
• в линию
• вложение

У вас уже достаточно писем с примерами?

У нас должен быть полный список тестовых случаев, чтобы охватить различные случаи, которые можно легко расширить в будущем.

отправка зашифрованных сообщений

Поскольку Zammad поддерживает только отправку электронных писем в формате HTML, нам нужно только покрыть отправку писем detached PGP.

Место, где Zammad создает электронное письмо из заданных атрибутов, находится в app/models/channel/email_build.rb в методе self.build . Это следует расширить, чтобы использовать класс PgpMessage для создания экземпляра с заданным атрибутом body и использовать методы encrypted и signed для создания зашифрованного PGP. и подписанный основной текст и вложения.
Для этого необходимо найти открытые ключи адресов электронной почты получателей. Как пользователи могут хранить свой ключ (в своем профиле) пока не ясно. Я обсужу это внутри и дам вам знать.

Я думаю, что не должно быть возможности отправлять незашифрованные письма, если PGP настроен и получатель поддерживает его. Нам нужно прояснить это, но до тех пор это должно быть так.

Интерфейс администратора

Это должно быть изолировано от основной функциональности и будет описано позже. Я думаю, вам понадобится наша поддержка в этом. Я обсужу это внутри и дам вам знать, как мы к этому подходим.

Вывод

К настоящему времени этого должно быть достаточно и указать в правильном направлении. Вероятно, мы дойдем до некоторых мест, где нам придется перестроиться и охватить другие случаи, но пусть они возникнут первыми.
Не стесняйтесь задавать любые вопросы, если они возникают.

Я с нетерпением жду возможности увидеть и просмотреть ваши изменения 🤓

Спасибо за вашу поддержку 🚀
Торстен

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

Интерфейс командной строки PGP нестабилен и, согласно GPG, не должен использоваться в качестве API. До сих пор я успешно использовал ruby-gpgme , так что сейчас я хотел бы следовать этому пути. Учитывая, что, насколько я знаю, GPG не имеет API, а только библиотеки уровня C, я не думаю, что мы обойдемся без каких-либо расширений C.. за исключением повторной реализации GPG в ruby, может быть, но Я не знаю ни одного.

Спасибо, что разъяснили. Я не знал об этом. Звучит хорошо для меня тогда. Немного беспокоит, что их сборки терпят неудачу, но я посмотрю на это.

Привет! Как обсуждалось ранее, эта проблема началась как запрос на функциональность PGP. Позже мы также добавили S/MIME. Но так как обе они реализуются независимо друг от друга и представляют собой разные технологии, мы решили перенести требование S/MIME в новый выпуск #1961. Не стесняйтесь подписываться там, если вы заинтересованы в каком-либо прогрессе. Обсуждения следует проводить на совете сообщества , чтобы избежать шума в системе отслеживания проблем. Спасибо!

Поэтому я предоставлю вам помощника RSpec, который облегчит тестирование и поддержит вас на пути, насколько это возможно. В ближайшие дни добавлю в ветку разработки.

@thorsteneckel уже приземлился, и если да, то где именно? :)

@luto - извините за задержку - вот он: https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Вам просто нужно поместить *filter_filename*_spec.rb в spec/models/channel/filter/ (как это сделано для models/channel/filter/follow_up_merged.rb и добавить , type: :channel_filter после имени вашего класса фильтра.
После этого у вас есть два помощника:

filter_parsed(mail_string) :
https://github.com/zammad/zammad/blob/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d/spec/support/channel_filter.rb#L17 -L27

и filter(parsed_mail_hash) :
https://github.com/zammad/zammad/blob/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d/spec/support/channel_filter.rb#L3 -L13

Именованный параметр channel является необязательным и в вашем случае не нужен.

Спасибо!
К вашему сведению: ветка теперь живет в нашем форке . не стесняйтесь комментировать любые коммиты, когда я иду. Это должно сделать окончательный обзор легким и коротким для всех участников :)

Привет @luto - здорово видеть, что ты работаешь над этим в таком темпе. Я заметил, что код не выглядит так, будто его проверяли с помощью rubocop. Мы используем rubocop и coffeelint, чтобы обеспечить руководство по стилю Zammad для обоих типов файлов. Существует даже конфигурация фильтра предварительной фиксации, если вы хотите выполнять проверки автоматически. Дайте мне знать, если я могу дать вам больше информации об этом.

О, конечно. Я установил хук с pre-commit install , а также соответствующее расширение для моего редактора . Отступ был исправлен с помощью filter-branch , поэтому история выглядит лучше; все остальные правонарушения фиксировались вручную. Полицейский теперь в основном доволен :)

Вы можете заметить в коде символ pythonism. Хотя я стараюсь подражать рубиновому способу делать вещи как можно лучше, я все еще занимаюсь питоном по профессии ;) Пожалуйста, просто укажите на вещи, если они кажутся вам обратными. Рубокоп поймал немало из них :sweat_smile:

Хороший! Я только что заметил, что есть по крайней мере один тип примененных изменений , которые не соответствуют нашей конфигурации rubocop: использование unless вместо отрицательных if s. Так что, похоже, ваш рубокоп много здесь делает.

О, pythonisms просто отлично для меня. Пока придраться не к чему 🤓

Привет @luto - я просто хотел посмотреть на текущее состояние разработки, но заметил, что за 24 дня не было никаких коммитов. Могу ли я что-нибудь сделать?

Могу ли я что-нибудь сделать?

исправляем другие наши внутренние проекты :wink: :grin:
Блокировщика в пределах Заммада нет, только общая нехватка времени. Работа над этим должна продолжиться на следующей неделе.

@thorsteneckel Я как бы попал в затруднительное положение. Gpg (или, по крайней мере, gpgme) в большинстве случаев не делает различий между «электронная почта зашифрована, но не может быть расшифрована» и «электронная почта зашифрована, и все в порядке». Такое поведение несовместимо с описанными ранее методами encrypted? и decryptable? . Прямо сейчас у меня есть несколько хаков для обнаружения зашифрованных, но не расшифровываемых писем, но я не могу заставить их работать во всех случаях.

Что вы думаете о том, чтобы не делать различия между дешифруемым и зашифрованным в пользовательском интерфейсе? За исключением очевидных случаев, таких как отсутствующий заголовок сообщения GPG, ofc.

Когда можно ожидать внедрения и интеграции в Zammad? Планируется ли реализация для конкретного релиза?

Какие-нибудь Новости?

У меня есть ощущение, что те, кто мог бы продвигать разработку этого плагина, думают о другом, кроме проверки ответов по этому вопросу.
Если вы хотите привлечь их внимание к этому, вы можете написать им по электронной почте: [email protected] — я уже сделал это — или отправить им дружеский твит @ubernauten

@hatscher извините за задержку; как догадался @0xErnie , у меня в настоящее время есть другие дела, но эта функция все еще находится на нашем радаре. Обратите внимание, что в настоящее время я работаю над этим соло, а не в составе команды Zammad, Inc. и без какой-либо внешней поддержки. Так что это может занять некоторое время.

Что касается блокировщиков, здесь есть один открытый вопрос для @thorsteneckel , а также частный вопрос о том, как мы собираемся решать этот компонент пользовательского интерфейса. Не стесняйтесь обращаться к нему, если вы хотите внести свой вклад, чтобы продвинуть это вперед, @hatscher! Однако главный блокирующий фактор — это нехватка времени.

Извините за поздний ответ, особенно вам, @luto ! Я не могу уделять этому время и внимание, в которых он нуждается в настоящее время. Планирую заняться этим через 2 недели.

Какие-нибудь Новости? Нам нужна эта функция...

@hatscher многим из нас это нужно :) Но в конце концов, все, кто работает над этой функцией (@luto), делают это добровольно :) Если в этом есть реальная коммерческая необходимость, я думаю, пожертвование (либо деньги, либо работа) помогло бы управлять вперед прогресс. К сожалению, у меня нет времени, чтобы внести свой вклад, поэтому все, что у меня осталось, это надежда и терпение :P

Говоря о вкладе: как насчет того, чтобы представить текущее состояние разработки в качестве PR, чтобы другие могли присоединиться, если они чувствуют, что могут внести свой вклад?

Учитывая печальное состояние GPG-API как в ruby, так и в целом, стоит взглянуть на новую реализацию GPG rust .

Недоверчиво:

ПРИВЯЗКИ СКОРО!

Есть ли новости об интеграции PGP и S/MIME? Я также хотел бы пожертвовать сумму, потому что мне срочно нужна эта функция.

Есть ли на самом деле список с запланированными функциями следующих версий?

Привет @hatscher ,
нам также нужен S/MIME, и мы ведем переговоры с Zammad о расходах. Хотим ли мы поговорить друг с другом, чтобы разделить расходы на интеграцию? Может быть, просто пришлите мне письмо (имя и фамилия де).

Электронная почта уже в пути ;-)

В настоящее время мы ищем других людей, которые готовы финансировать эту функцию (возможно, также вместе с шифрованием S/MIME в качестве пакета). Пожалуйста, свяжитесь со мной, если вас интересует мое имя на фамилию .de. Я проверю и посмотрю, сколько желающих, чтобы мы могли просто разделить расходы.

@martinseener Приятно слышать, что вы пытались получить финансирование для этой функции. Не могли бы вы поделиться достигнутым прогрессом или проблемами, с которыми вы столкнулись? Служба поддержки PGP в настоящее время принимает решение о переходе на Zammad, поэтому любая информация будет оценена по достоинству.

Извините, но в данный момент мы не можем поделиться какой-либо информацией по этой теме.
Мы соответствующим образом обновим эту проблему, как только что-то изменится для Zammad-Core.

Глядя на время вашего ответа в несколько месяцев и предыдущие обсуждения этого вопроса, я прихожу к выводу, что добавление поддержки PGP в Zammad не является для вас приоритетом или не произойдет вообще. (Просто резюмирую здесь для тех, кто появится в будущем и не захочет читать все обсуждение.)

Привет , @rixx , ты прав. В настоящее время мы работаем над задачами на основе нашей схемы приоритетов:

1-й: поддержка/индивидуальная разработка
Это люди, финансирующие Zammad и функции, которые мы выпускаем. Без них Заммада не было бы здесь сегодня. Их наличие действительно много значит для нас и подтверждает, что мы на правильном пути.

2-й: 80% особенностей/проблем
Свободное время, которое мы получаем от поддержки наших клиентов, мы тратим на 100% в продукте. Для нас важно быть одинаково справедливыми по отношению к любому пользователю из нашей пользовательской базы. Однако, как только дело доходит до деталей, нам приходится принимать все больше и больше решений в пользу одной стороны, а не другой. Поэтому мы работаем только над функциями и проблемами, которые затрагивают 80% нашей пользовательской базы. Таким образом, мы можем гарантировать, что большая часть нашей пользовательской базы получит выгоду от вносимых нами изменений.

3-й: Личный интерес
Здесь, в Zammad, каждый волен тратить время на задачи, которые представляют для него личный интерес. Если вы еще раз осмотритесь, то заметите, что мы отвечаем на проблемы и вопросы, которые не попадают в категорию финансируемых или наиболее важных изменений. Это потому, что мы действительно заботимся и любим помогать людям. Однако это в основном небольшие задачи, потому что свободное время в настоящее время очень ограничено - к сожалению.

Теперь вернемся к теме: в настоящее время PGP не попадает ни в одну из перечисленных выше категорий. Вот почему вы правы, когда говорите, что в настоящее время это не является для нас приоритетом. Однако вы ошибаетесь, когда говорите, что PGP вообще не будет. PGP имеет сравнительно высокий приоритет для нас, на самом деле он находится в нашем внутреннем черновике общедоступной дорожной карты, которая включает только самые важные изменения.
Так что время для PGP еще не пришло, но обязательно придет. В зависимости от схемы приоритета - рано или поздно.
Чего мне не хватает в вашем резюме, так это того факта, что разработка PGP на самом деле уже началась как усилия сообщества @luto при нашей поддержке (еще раз спасибо @luto !). К сожалению, приоритет сместился, и изменение в настоящее время устарело. Тем не менее, все, у кого есть знания и возможность взяться за дело и продолжить работу над ним, мы обязательно поддержим!

Также есть новости для всех, кто интересуется общей темой зашифрованной связи: замечательные люди вокруг @martinseener на barzahlen.de профинансировали разработку связи S/MIME (#1961), которая скоро будет запущена.

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

Есть новости о "коммуникациях S/MIME"?

Если вам нужно спросить, пожалуйста, по крайней мере, используйте правильное место: https://github.com/zammad/zammad/issues/1961

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

Если у нас есть какие-либо обновления по этому вопросу, мы соответствующим образом обновим эту проблему.

Как вы могли видеть в #1961, мы добавили поддержку S/MIME и выпустим ее в следующей версии 3.4 Zammad 🎉 Огромное спасибо @martinseener на barzahlen.de за спонсорство и, следовательно, за то, что это стало возможным 🙌
К сожалению, у нас все еще нет необходимых ресурсов для добавления поддержки PGP. Мы думали о тестировании некоторых вещей, но пока не было возможности. Вот почему я хотел дать вам краткое обновление здесь.
Однако интеграция S/MIME обеспечивает почти полную «основу» для обработки защищенной рассылки и хорошую справочную реализацию того, как все должно быть интегрировано/построено. @luto по-прежнему проделал большую работу на развилке Uberspace . Если кто-то готов рискнуть, мы будем рады помочь всем, чем сможем. Просто откройте тему на форуме сообщества и упомяните меня.

Мы держим вас в курсе по мере поступления новой информации - обещано ✌️