Zammad: PGP

+1 para suporte S/MIME

Ok, mudei o título. O melhor, é claro, se oferecesse as duas coisas.

Eu gostaria de ter a possibilidade de enviar e receber e-mails criptografados X.509.

SIM, seria muito bom poder enviar e receber mensagens X.509 assinadas ou criptografadas.

Assim, os e-mails criptografados X.509 são e-mails S/MIME. Pessoalmente, gostaria mais do PGP (também porque é mais difundido), mas esse problema é sobre os dois sistemas. 😃

Eu adicionaria notificações criptografadas à lista de desejos - portanto, os usuários precisam adicionar a chave pública ao perfil.

FYI: Existe um bom plugin com essa funcionalidade para redmine: https://github.com/C3S/redmine_openpgp

Esta gem parece não ser realmente mantida (last commit ), mas existem várias outras . Pessoalmente, eu diria que esta jóia tem o commit mais recente.

Hoje tivemos a primeira solicitação de cliente solicitando PGP-Support porque ela não queria solicitar seus dados bancários por meio de uma conexão não criptografada. Portanto, +1

+1.
Estamos trabalhando com a comunidade IT SEC e recebemos toneladas de e-mails criptografados PGP que não podemos abrir em Zammad, então temos que exportar e descriptografar, é um fluxo de trabalho infernal. +1 por suportar PGP e talvez S/MIME Mails em Zammad :)

Hoje em dia a criptografia de e-mail é uma obrigação. O Regulamento Geral de Proteção de Dados (GDPR) exige Privacidade por Design e por Padrão e de acordo com o estado da arte.

Tecnicamente, isso pode ser fácil de resolver integrando o mecanismo p≡p (privacidade bastante fácil).

+1
Muitas vezes recebemos e-mails criptografados. Exportar e descriptografar manualmente os tickets criptografados é doloroso e, por isso, não podemos responder aos tickets pelo sistema de tickets.

+1
Sem PGP/GPG não consigo migrar do OTRS para o Zammad. Eu tenho muitos tickets criptografados com gnupg no meu antigo OTRS.

+1

Gostaríamos que o GnuPG assine todos os e-mails de tickets enviados após um caso muito feio de falsificação de nosso e-mail para roubar nossos clientes.

Talvez o PeP possa ser integrado, pois é uma solução fácil e utilizável para criptografia PGP.

Eu também acho que seria um ótimo recurso para enviar e-mails assinados. Isso daria algum grau de confiança para o destinatário, que o endereço é real e pode ser confiável.

O próximo passo seria criptografar totalmente a mensagem.

@martini @monotek , estamos pensando em lidar com a parte GPG disso, internamente. Há alguma restrição com a fusão disso, se o fizermos? alguma funcionalidade que você gostaria de ver ou exigir?

Oi @luto - parece bom! Os itens necessários para uma mesclagem são:

• Testes, de preferência RSpec
• Documentação
• Documentação da API de código
• Código QAd através da nossa configuração rubocop e coffeelint

Já vimos algumas gems Ruby que fornecem uma API para o binário gpg CLI. Tanto quanto me lembro, nenhum deles parecia realmente promissor. Certifique-se de confiar apenas em dependências mantidas/de qualidade, pois esse é um ponto crítico.
Uma implementação personalizada é possível, mas tenha em mente a extensibilidade e a manutenção. Não coloque toda a lógica no módulo, mas crie uma classe lib para ele. Respeite o princípio da responsabilidade única.

A funcionalidade deve incluir todas as variações de assinatura, verificação e descriptografia de envio e recebimento de e-mails 🤓
O tratamento das mensagens recebidas deve ser feito o mais cedo possível para que o conteúdo seja acessível em outros componentes.
O tratamento das mensagens enviadas deve ser feito o mais tarde possível para poder acessar o conteúdo em outros componentes.

Deve haver uma boa interface de administração para gerenciar chaves públicas e privadas.

Sinta-se à vontade para entrar em contato conosco em [email protected] para tirar todas as suas dúvidas e obter nosso suporte sobre isso. Estamos mais do que felizes em receber o seu 💪 Vamos fazer do jeito Zammad 🏎

Também recebemos o primeiro cliente que exige essa comunicação, então também voto nesse. Já existe algum progresso? Eu também gostaria de ajudar a testar um beta.

@martinseener afaik isso não está no roteiro da equipe Zammad. No momento, estamos planejando implementar isso por conta própria. Se você quiser fazer um chip, para que possamos fazer isso mais rápido e você possa atender seu cliente, sinta-se à vontade para entrar em contato pelo endereço de e-mail no meu perfil do github.

@thorsteneckel Atualmente estou prototipando uma implementação para receber e-mails em duas partes:

1. descriptografar o e-mail em Postmaster::PreFilter : definir a mensagem descriptografada como conteúdo; jogue fora o original; armazenar a chave de descriptografia usada nos metadados
2. em Postmaster::PostFilter crie um objeto GpgCryptoInfo , anexe-o ao Article ; armazenar informações como a chave de descriptografia usada e o status da assinatura permanentemente

Algumas perguntas:

• você acha que isso deve ser implementado usando essas APIs de filtro? Ou isso deve ser codificado em Channel::EmailParser ?
• existem assinantes Postmaster::PreFilter que precisam de acesso ao conteúdo da mensagem descriptografada? Nesse caso, é necessária uma implementação codificada ou Postmaster::EarlyPreFilter .
• há alguma informação, exceto a chave usada para criptografar/descriptografar/assinar/verificar, bem como o status da assinatura do e-mail recebido que você gostaria de ver mantido permanentemente?

Além disso, uma pergunta geral: EmailParser ou os filtros parecem ser o lugar perfeito para _descriptografar_ e-mails; você pode pensar em um lugar "perfeito" para criptografá-los?

Espero que esta edição seja o lugar certo para fazer perguntas de implementação. Se não, por favor me indique outro, de preferência público, um :) Obrigado!

Oi @luto - Atualmente estou escrevendo meus pensamentos sobre isso. Por ser um tópico bastante grande e importante, leva algum tempo. Tento fazer até o final da semana. Obrigado pela sua compreensão.

Pequena atualização: os filtros Postmaster::PreFilter são ordenados. Atualmente, coloquei o meu logo após IdentifySender , para que eu possa descobrir quais chaves gpg tentar. Sabendo disso, os filtros parecem ser o lugar certo para descriptografar para mim.

@thorsteneckel Obrigado por dedicar seu tempo! Aguardo sua escrita. :)

Oi @luto , fico feliz em saber disso! Eu gosto de ter a coordenação nesta questão como você propôs. Portanto, será transparente e poderemos reutilizar as informações compartilhadas para uma documentação técnica. Você pode consultar esse problema em sua ramificação de trabalho do seu fork e ele será referenciado aqui. Por favor, crie um Pull Request após a conclusão das alterações. Enquanto isso, vou verificar sua filial e ver as alterações.
Devemos mover a funcionalidade S/MIME para um problema separado, pois não a implementaremos agora.

Em relação às suas perguntas: Você está totalmente no caminho certo. Vou escrever algumas coisas e responder suas perguntas no caminho.

Desenvolvimento geral

Em nossa experiência, o desenvolvimento orientado a testes (com RSpec) funciona melhor para esse tipo de tarefa. Depende de você como você aborda isso, mas definitivamente precisaremos de um conjunto de testes abrangente para a funcionalidade. Portanto, fornecerei um ajudante RSpec para facilitar os testes e apoiá-lo da melhor maneira possível. Vou adicioná-lo ao ramo develop nos próximos dias. Você deve usar esta ramificação como sua base, pois ela também é nossa ramificação de trabalho. Ele será mesclado no mestre e substituirá o estável no futuro.

Postmaster::PreFilter

Postmaster::PreFilter s são o lugar certo. Você pode influenciar o tempo de execução por um prefixo numérico no nome do registro do filtro . Números mais baixos serão executados mais cedo .
Para sistemas já inicializados, uma migração que adiciona a configuração também é necessária .
Eu proporia um nome como app/models/channel/filter/decrypt.rb - mas no final fica a seu critério.

Após o registro, o Zammad executará o filtro para cada e-mail recebido.

classe de mensagem PGP

Como só implementaremos o PGP neste momento, temos que ter certeza de que não adicionaremos obstáculos para adicionar S/MIME posteriormente. Além disso, pode ser necessário, no futuro, oferecer suporte a PGP em outros canais que não apenas e-mail. Ter isso em mente garantirá que o back-end e a API que projetamos sejam fáceis de testar e integrar. Seguindo minha proposta (aberta para discussão):

Deve haver uma classe chamada PgpMessage localizada no arquivo lib/pgp_message.rb . Esta classe recebe um argumento obrigatório que será (possivelmente) a string de mensagem/conteúdo de e-mail criptografado. Exemplo:

instance = PgpMessage.new(email_content)

A instância deve fornecer a seguinte interface:

• #assinado?
• #verified?(signature) # assinatura é opcional e pode ser uma assinatura externa de, por exemplo, um anexo
• #signature_error
• #criptografado?
• #descriptável?
• #descriptografado
• #chave
• #decryption_error
• #encrypt( public_key(s) )
• #sinal

Interface PGP

Para ser sincero, não encontrei nenhuma joia que goste de ter como dependência. Todos eles parecem não mantidos, complexos ou precisam de compilação de extensões em C. Pode valer a pena tentar se não pudermos acessar a CLI do PGP. O que você acha?

Integração PgpMessage no Postmaster::PreFilter para descriptografia

A classe PgpMessage pode ser usada no Postmaster::PreFilter para inicializar uma instância e verificar a relevância da mensagem. Se for uma mensagem criptografada por PGP, podemos usar os outros métodos para extrair os dados de que precisamos e sobrescrever o conteúdo de body e attachments no hash mail .
Além disso, temos que armazenar algumas meta-informações (como você já afirmou) no artigo que será criado definindo o cabeçalho x-zammad-article-preferences :

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

Acho que os seguintes metadados devem ser suficientes:

• chave_decriptografia <- chave
• decryption_error <- decryption_error (em caso de existência)
• mensagem_criptografada <- mail['body']
• signature_status <- verificado?
• signature_error <- signature_error (caso exista)

variações suportadas de mensagens descriptografáveis

A classe PgpMessage deve ser capaz de manipular (pelo menos?) as seguintes combinações e variações de mensagens PGP recebidas:

• criptografado
• assinado
• criptografado + assinado
• em linha
• acessório

Você já tem e-mails de exemplo suficientes?

Temos que ter uma lista abrangente de casos de teste para cobrir vários casos que podem ser estendidos facilmente no futuro.

enviando mensagens criptografadas

Como o Zammad suporta apenas o envio de e-mails HTML , precisamos apenas cobrir o envio de e-mails detached PGP.

O local onde o Zammad cria um e-mail a partir de determinados atributos está em app/models/channel/email_build.rb no método self.build . Isso deve ser estendido para usar a classe PgpMessage para criar uma instância com o atributo body e usar os métodos encrypted e signed para criar o PGP criptografado e conteúdo do corpo e anexos assinados.
Para fazer isso, é necessário pesquisar as chaves públicas dos endereços de e-mail dos destinatários. Como os usuários podem armazenar sua chave (em seu perfil) ainda não está claro. Vou discutir isso internamente e te aviso.

Eu acho que não deve haver opção para enviar e-mails não criptografados uma vez que o PGP esteja configurado e o destinatário o suporte. Precisamos esclarecer isso, mas até então esse deve ser o caminho a seguir.

Interface do administrador

Isso deve ser isolado da funcionalidade principal e será descrito posteriormente. Acho que você vai precisar do nosso apoio nisso. Vou discuti-lo internamente e informá-lo como abordamos isso.

Conclusão

Isso deve ser suficiente agora e apontar na direção certa. Provavelmente chegaremos a alguns pontos onde teremos que realinhar e cobrir outros casos, mas deixá-los surgir primeiro.
Sinta-se à vontade para fazer quaisquer perguntas se surgirem.

Estou ansioso para ver e revisar suas alterações 🤓

Obrigado pelo apoio 🚀
Thorsten

Para ser sincero, não encontrei nenhuma joia que goste de ter como dependência. Todos eles parecem não mantidos, complexos ou precisam de compilação de extensões em C. Pode valer a pena tentar se não pudermos acessar a CLI do PGP. O que você acha?

A CLI do PGP não é estável e deve, de acordo com o GPG, não ser usada como API. Eu tive sucesso usando ruby-gpgme até agora, então essa é a rota que eu gostaria de seguir por enquanto. Dado que, tanto quanto eu sei, o GPG não tem uma API, mas apenas bibliotecas de nível C, não acho que sairemos sem nenhuma extensão C .. exceto por uma reimplementação do GPG em ruby, talvez, mas Eu não sei de nenhum.

Obrigado por deixar claro. Eu não estava ciente disso. Soa-me bem então. É um pouco preocupante que suas compilações estejam falhando, mas vou dar uma olhada nisso.

Ei! Conforme discutido anteriormente, este problema começou como uma solicitação para a funcionalidade PGP. Mais tarde, adicionamos S/MIME também. Mas como ambos são implementados independentemente e são tecnologias diferentes, decidimos mover o requisito S/MIME para a nova edição #1961. Sinta-se à vontade para se inscrever por lá se estiver interessado em algum progresso. As discussões devem ser feitas no conselho da comunidade para evitar ruídos no rastreador de problemas. Obrigado!

Portanto, fornecerei um ajudante RSpec para facilitar os testes e apoiá-lo da melhor maneira possível. Vou adicioná-lo ao ramo de desenvolvimento nos próximos dias.

@thorsteneckel já chegou e se sim, onde exatamente está? :)

@luto - desculpe a demora - aqui está: https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Você só precisa colocar *filter_filename*_spec.rb em spec/models/channel/filter/ (como feito para models/channel/filter/follow_up_merged.rb e adicionar , type: :channel_filter após o nome da classe de filtro.
Depois disso, você tem dois ajudantes disponíveis:

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

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

O parâmetro nomeado channel é opcional e não deve ser necessário no seu caso.

Obrigado!
FYI: o ramo vive em nossa bifurcação agora. sinta-se à vontade para comentar sobre qualquer um dos commits conforme eu for. Isso deve manter a revisão final fácil e curta para todos os envolvidos :)

Oi @luto - ótimo ver você trabalhando nisso com tanto ritmo. Percebi que o código não parece ter sido verificado com o rubocop. Usamos rubocop e coffeelint para garantir o guia de estilo Zammad para ambos os tipos de arquivos. Existe até uma configuração de filtro de pré-confirmação disponível se você quiser realizar as verificações automaticamente. Deixe-me saber se eu posso lhe dar mais informações sobre isso.

Ah, com certeza. Eu instalei o gancho com pre-commit install bem como a extensão correspondente para meu editor . O recuo foi corrigido via filter-branch , então o histórico parece melhor; todas as outras ofensas foram fixadas à mão. O policial está mais feliz agora :)

Você pode notar um com pythonisms no código. Enquanto eu tento imitar o jeito rubi de fazer as coisas da melhor maneira possível, ainda sou um cara de python por profissão ;) Por favor, apenas aponte as coisas, se elas parecerem atrasadas para você. Rubocop pegou alguns deles :sweat_smile:

Agradável! Acabei de notar que há pelo menos um tipo de alteração aplicada que não corresponde à nossa configuração do rubocop: Usando unless em vez de if s negativos. Então parece que seu rubocop está fazendo muito aqui.

Oh os pythonisms é muito bom para mim. Nada a reclamar até agora 🤓

Oi @luto - Eu só queria dar uma olhada no estado atual do desenvolvimento, mas notei que não havia nenhum commit desde 24 dias. Há algo que eu possa fazer?

Há algo que eu possa fazer?

consertando nossos outros projetos internos :wink: :grin:
Não há bloqueador dentro dos limites de Zammad, apenas uma falta geral de tempo. O trabalho sobre isso deve continuar na próxima semana.

@thorsteneckel eu meio que bati em um obstáculo. Gpg (ou pelo menos gpgme) não faz distinção entre "o e-mail é criptografado, mas não pode descriptografar" e "o e-mail é criptografado e está tudo bem" na maioria dos casos. Esse comportamento não é compatível com os métodos encrypted? e decryptable? descritos anteriormente. No momento, tenho vários hacks para detectar e-mails criptografados, mas não descriptografáveis, mas não consigo fazê-lo funcionar em todos os casos.

O que você acha de não fazer distinção entre descriptografável e criptografado na interface do usuário? Exceto para casos óbvios como um cabeçalho de mensagem GPG ausente, ofc.

Quando podemos esperar a implementação e integração no Zammad? A implementação está planejada para uma versão específica?

Alguma novidade?

Tenho a sensação de que aqueles que poderiam antecipar o desenvolvimento deste plugin têm outras coisas em mente, mas verificam as respostas sobre este problema.
Se você quiser chamar a atenção deles para isso, escreva um e-mail para eles: [email protected] - eu já fiz isso - ou envie um tweet amigável @ubernauten

@hatscher desculpe a demora; como @0xErnie adivinhou, atualmente tenho outras coisas para fazer, mas esse recurso ainda está em nosso radar. Por favor, note que atualmente estou trabalhando neste solo, não como parte da equipe Zammad, Inc. e sem qualquer fundação externa. Então isso pode demorar um pouco.

Quanto aos bloqueadores, há uma pergunta para @thorsteneckel aberta aqui, bem como uma pergunta privada sobre como vamos lidar com o componente da interface do usuário. Sinta-se à vontade para entrar em contato com ele, se quiser contribuir para avançar, @hatscher! O principal bloqueador é a minha falta de tempo, no entanto.

Desculpe a demora na resposta, especialmente para você @luto ! Não posso dar a isso o tempo e a atenção de que precisa atualmente. Eu pretendo resolver isso em 2 semanas a partir de agora.

Alguma novidade? Precisamos desse recurso...

@hatscher muitos de nós precisam disso :) Mas afinal, todo mundo que está trabalhando no recurso (@luto) faz isso voluntariamente :) Se houver uma necessidade comercial real para isso, acho que doar (um pouco de dinheiro ou trabalho) ajudaria a dirigir encaminhar o progresso. Infelizmente não tenho tempo para contribuir, então só me resta esperança e paciência :P

Falando sobre contribuições: Que tal enviar o estado atual de desenvolvimento como PR para que outros possam participar se sentirem que podem contribuir?

Dado o triste estado das GPG-APIs tanto em ruby ​​quanto em geral, a nova implementação de ferrugem GPG pode valer a pena dar uma olhada.

Com um grão de sal:

LIGAÇÕES EM BREVE!

Há alguma novidade sobre a integração PGP e S/MIME? Também gostaria de doar uma quantia, pois preciso urgentemente desse recurso.

Existe realmente uma lista com os recursos planejados das próximas versões?

Olá @hatscher ,
também precisamos de S/MIME e estamos conversando com Zammad sobre os custos. Queremos conversar uns com os outros para talvez dividirmos os custos da integração? Talvez apenas me envie um e-mail (nome no sobrenome de).

O e-mail está a caminho ;-)

No momento, estamos procurando outras pessoas dispostas a financiar esse recurso (talvez também junto com a criptografia S/MIME como um pacote). Por favor contacte-me se estiver interessado no meu nome próprio em lastname .de. Vou verificar e ver quantas pessoas dispostas estão lá para que possamos dividir os custos.

@martinseener Ótimo saber que você tentou garantir financiamento para esse recurso. Você poderia compartilhar o progresso feito ou os problemas que você encontrou? O suporte do PGP está atualmente tomando ou quebrando uma decisão sobre uma mudança para Zammad, então qualquer insight seria apreciado.

Desculpe, mas neste momento não podemos compartilhar nenhuma informação sobre este tópico.
Atualizaremos esse problema assim que algo acontecer para o Zammad-Core.

Olhando para o seu tempo de resposta de vários meses e as discussões anteriores sobre este assunto, estou concluindo que adicionar suporte PGP ao Zammad não é uma prioridade para você ou não acontecerá. (Apenas resumindo aqui para quem vier no futuro e não quiser ler toda a discussão.)

Ei @rixx - você está certo. Atualmente, estamos trabalhando em tarefas com base em nosso esquema de prioridade:

1º: suporte/desenvolvimento customizado
Essas são as pessoas que financiam o Zammad e os recursos que lançamos. Zammad não estaria aqui hoje sem eles. Tê-los realmente significa muito para nós e encoraja que estamos no caminho certo.

2º: 80% de recursos/problemas
O tempo livre que ganhamos com o suporte de nossos clientes é gastar 100% no produto. É importante para nós sermos igualmente justos com qualquer usuário de nossa base de usuários. No entanto, assim que se chega aos detalhes, há cada vez mais decisões que precisamos tomar em favor de uma parte em detrimento da outra. Portanto, trabalhamos apenas em recursos e problemas que afetam 80% de nossa base de usuários. Dessa forma, podemos garantir que a maioria de nossa base de usuários lucre com as alterações que introduzimos.

3º: Interesse pessoal
Aqui na Zammad todos são livres para gastar tempo em tarefas que são de seu interesse pessoal. Se você der uma segunda olhada, perceberá que respondemos a problemas e perguntas que não se enquadram na categoria de alterações financiadas ou mais relevantes. Isso ocorre porque realmente nos importamos e gostamos de ajudar as pessoas. No entanto, estas são principalmente tarefas menores porque o tempo livre é atualmente muito limitado - infelizmente.

Agora, voltando ao tópico: o PGP atualmente não se enquadra em nenhuma das categorias listadas acima. É por isso que você está certo ao dizer que atualmente não é uma alta prioridade para nós. No entanto, você está errado quando diz que o PGP não acontecerá. O PGP tem uma prioridade comparativamente alta para nós, na verdade está em nosso rascunho interno para o roteiro público que inclui apenas as mudanças mais relevantes.
Portanto, a hora do PGP ainda não chegou, mas certamente chegará. Dependendo do esquema de prioridade - mais cedo ou mais tarde.
O que está faltando no seu resumo é o fato de que o desenvolvimento do PGP na verdade já foi iniciado como um esforço da comunidade por @luto com nosso apoio (obrigado novamente @luto !). Infelizmente, a prioridade mudou e a mudança está obsoleta. No entanto, todos com o conhecimento e a capacidade de pegar as coisas e continuar trabalhando serão apoiados por nós com certeza!

Também há novidades para qualquer pessoa interessada no tópico geral de comunicação criptografada: O grande pessoal em torno de @martinseener em barzahlen.de financiou o desenvolvimento da comunicação S/MIME (#1961) - que em breve será iniciada.

Se você estiver interessado em aprofundar esta discussão ou até mesmo contribuir, sinta-se à vontade para abrir um tópico ou me enviar uma PM no fórum da comunidade e manter este assunto no tópico.

Alguma notícia sobre "comunicação S/MIME"?

Se você tiver que perguntar, por favor, use pelo menos o lugar certo: https://github.com/zammad/zammad/issues/1961

Desculpe, devido à falta de feedback nos últimos meses, estou limitando este problema apenas aos colaboradores.
Isso é para reduzir o ruído e nos ajuda a nos concentrar nos problemas.

Se tivermos alguma atualização sobre isso, atualizaremos esse problema de acordo.

Como você deve ter visto no #1961, adicionamos suporte S/MIME e o lançaremos com a próxima versão 3.4 do Zammad 🎉 Muito obrigado a @martinseener em barzahlen.de por patrociná-lo e torná-lo possível
Infelizmente ainda não temos os recursos necessários para adicionar suporte a PGP também. Estávamos pensando em testar algumas coisas, mas ainda não tivemos a chance. É por isso que eu queria dar-lhe uma breve atualização aqui.
No entanto, a integração S/MIME fornece uma "estrutura" quase completa para lidar com correspondência segura e uma boa implementação de referência sobre como as coisas devem ser integradas/construídas. Ainda tem o ótimo trabalho inicial feito pelo @luto lá na bifurcação do Uberspace . Se alguém estiver disposto a arriscar, ficaremos felizes em ajudar com tudo o que pudermos. Basta abrir um tópico no fórum da comunidade e me mencionar.

Mantemos você atualizado à medida que novas informações estão disponíveis - prometido ✌️