Zammad: PGP

+1 pour la prise en charge S/MIME

Bon, j'ai changé le titre. Le mieux serait bien sûr s'il offrait les deux choses.

J'apprécierais d'avoir la possibilité d'envoyer et de recevoir des mails cryptés X.509.

OUI, ce serait très bien de pouvoir envoyer et recevoir des mails X.509 signés ou cryptés.

Ainsi, les mails cryptés X.509 sont des mails S/MIME. Personnellement, j'aimerais davantage PGP (également parce qu'il est plus répandu), mais ce problème concerne les deux systèmes. 😃

J'ajouterais des notifications cryptées à la liste de souhaits - les utilisateurs doivent donc pouvoir ajouter leur clé publique à leur profil.

Pour info : Un joli plugin avec une telle fonctionnalité existe pour redmine : https://github.com/C3S/redmine_openpgp

Ce joyau ne semble pas vraiment maintenu (dernier commit), mais il en existe de multiples autres . Personnellement, je dirais que ce joyau a le commit le plus récent.

Aujourd'hui, nous avons eu la première demande client demandant PGP-Support car elle ne voulait pas demander ses coordonnées bancaires via une connexion non cryptée. Donc +1

+1.
Nous travaillons avec la communauté IT SEC et recevons des tonnes de mails cryptés PGP que nous ne pouvons pas ouvrir dans Zammad, nous devons donc exporter et décrypter, c'est un sacré workflow. +1 pour la prise en charge des courriers PGP et peut-être S/MIME dans Zammad :)

De nos jours, le cryptage des e-mails est indispensable. Le règlement général sur la protection des données (RGPD) exige la confidentialité dès la conception et par défaut et selon l'état de l'art.

Techniquement, cela pourrait être facile à résoudre en intégrant le moteur p≡p (confidentialité assez facile).

+1
Nous recevons souvent des mails cryptés. L'exportation et le décryptage manuel des tickets cryptés sont pénibles, et nous ne pouvons même pas répondre aux tickets via le système de tickets.

+1
Sans PGP/GPG, je ne peux pas migrer d'OTRS vers Zammad. J'ai de nombreux tickets cryptés avec gnupg dans mon ancien OTRS.

+1

Nous aimerions que GnuPG signe tous les e-mails de tickets sortants après un cas très laid de falsification de notre e-mail pour voler nos clients.

Peut-être que PeP pourrait être intégré car il s'agit d'une solution simple et utilisable pour le cryptage PGP.

Je pense aussi que ce serait une excellente fonctionnalité d'envoyer des e-mails signés. Cela donnerait un certain degré de confiance au destinataire, que l'adresse est réelle et digne de confiance.

La prochaine étape serait de chiffrer entièrement le message.

@martini @monotek, nous pensons nous attaquer nous-mêmes à la partie GPG, en interne. Y a-t-il des restrictions à la fusion, si nous le faisons ? une fonctionnalité que vous aimeriez voir ou dont vous auriez besoin ?

Salut @luto - ça sonne bien ! Les éléments requis pour une fusion sont :

• Tests, de préférence RSpec
• Documentation
• Documentation de l'API de code
• Code QAd via notre configuration rubocop et coffeelint

Nous avons déjà examiné certaines gemmes Ruby qui fournissent une API au binaire CLI gpg. Autant que je m'en souvienne, aucun d'entre eux ne semblait vraiment prometteur. Assurez-vous de ne compter que sur des dépendances maintenues/de qualité, car il s'agit d'un point critique.
Une implémentation personnalisée est possible, mais gardez à l'esprit l'extensibilité et la maintenance. Ne mettez pas toute la logique dans le module mais créez une classe lib pour cela. Respecter le principe de responsabilité unique.

La fonctionnalité doit inclure toutes les variantes de signature, de vérification et de cryptage/décryptage de l'envoi et de la réception des e-mails 🤓
La gestion des messages entrants doit être effectuée le plus tôt possible pour que le contenu soit accessible dans d'autres composants.
La gestion des messages sortants doit être effectuée le plus tard possible pour pouvoir accéder au contenu des autres composants.

Il devrait y avoir une belle interface d'administration pour gérer les clés publiques et privées.

N'hésitez pas à nous contacter à [email protected] pour poser toutes vos questions et obtenir notre soutien à ce sujet. Nous sommes plus qu'heureux de recevoir le vôtre 💪 Faisons-le à la manière de Zammad 🏎

Nous avons également le premier client qui nécessite une telle communication, donc je vote également pour celui-ci. Y a-t-il déjà des progrès ? J'aimerais aussi aider à tester une version bêta.

@martinseener autant que je sache, ce n'est pas sur la feuille de route de l'équipe Zammad. Nous prévoyons actuellement de mettre cela en œuvre par nous-mêmes. Si vous souhaitez participer, afin que nous puissions le faire plus rapidement et que vous puissiez servir votre client, n'hésitez pas à me contacter via l'adresse e-mail sur mon profil github.

@thorsteneckel Je suis actuellement en train de prototyper une implémentation pour recevoir des mails en deux parties :

1. déchiffrer le courrier dans Postmaster::PreFilter : définir le message déchiffré comme contenu ; jeter l'original; stocker la clé de déchiffrement utilisée dans les métadonnées
2. dans Postmaster::PostFilter créez un objet GpgCryptoInfo , attachez-le au Article ; stocker en permanence des informations telles que la clé de déchiffrement utilisée et l'état de la signature

Quelques questions :

• pensez-vous que cela devrait être implémenté à l'aide de ces API de filtrage ? Ou cela devrait-il être codé en dur dans Channel::EmailParser ?
• y a-t-il des abonnés Postmaster::PreFilter qui ont besoin d'accéder au contenu des messages décryptés ? Dans ce cas, une implémentation codée en dur ou un Postmaster::EarlyPreFilter est nécessaire.
• y a-t-il des informations, à l'exception de la clé utilisée pour chiffrer/déchiffrer/signer/vérifier ainsi que l'état de la signature du courrier reçu, que vous aimeriez voir conservées en permanence ?

Aussi, une question générale : EmailParser ou les filtres semblent être l'endroit idéal pour _déchiffrer_ les mails ; pouvez-vous penser à un endroit "parfait" pour les chiffrer ?

J'espère que ce numéro est le bon endroit pour poser des questions de mise en œuvre. Si ce n'est pas le cas, merci de m'en indiquer une autre, de préférence publique :) Merci !

Salut @luto - J'écris actuellement mes réflexions à ce sujet. Comme il s'agit d'un sujet assez vaste et important, cela prend du temps. J'essaie de le faire d'ici la fin de la semaine. Merci pour votre compréhension.

Petite mise à jour : les filtres Postmaster::PreFilter sont commandés. J'ai actuellement placé le mien juste après IdentifySender , afin que je puisse déterminer quelles clés gpg essayer. Sachant cela, les filtres semblent être le bon endroit pour décrypter pour moi.

@thorsteneckel Merci d'avoir pris le temps ! Dans l'attente de votre rédaction. :)

Salut @luto , content d'entendre ça ! J'aime avoir la coordination dans ce dossier comme vous l'avez proposé. Ainsi, ce sera transparent et nous pourrons réutiliser les informations partagées pour une documentation technique. Vous pouvez vous référer à ce problème dans votre branche de travail de votre fork et il sera référencé ici. Veuillez créer une demande d'extraction une fois les modifications terminées. En attendant, je vais vérifier votre succursale et voir les changements.
Nous devrions déplacer la fonctionnalité S/MIME vers un problème distinct puisque nous ne l'implémenterons pas maintenant.

Concernant vos questions : Vous êtes totalement sur la bonne voie. Je vais écrire certaines choses et répondre à vos questions en cours de route.

Développement général

D'après notre expérience, le développement piloté par les tests (avec RSpec) fonctionne mieux pour ce type de tâches. C'est à vous de décider comment vous l'abordez, mais nous aurons définitivement besoin d'une suite de tests complète pour la fonctionnalité. Par conséquent, je vous fournirai un assistant RSpec pour faciliter les tests et vous aider du mieux que je peux. Je l'ajouterai à la branche develop dans les prochains jours. Vous devriez utiliser cette branche comme base car c'est aussi notre branche de travail. Il sera fusionné avec master et remplacera stable à l'avenir.

Postmaster ::Préfiltre

Postmaster::PreFilter s sont au bon endroit. Vous pouvez influencer le temps d'exécution par un préfixe numérique dans le nom de l'enregistrement du filtre . Les nombres inférieurs seront exécutés plus tôt .
Pour les systèmes déjà initialisés, une migration qui ajoute le paramètre est également nécessaire .
Je proposerais un nom quelque chose comme app/models/channel/filter/decrypt.rb - mais à la fin c'est à vous de décider.

Une fois l'enregistrement terminé, Zammad exécutera le filtre pour chaque courrier entrant.

Classe de messages PGP

Puisque nous n'implémenterons que PGP à ce stade, nous devons nous assurer que nous n'ajouterons pas d'obstacles à l'ajout ultérieur de S/MIME. De plus, il pourrait être nécessaire à l'avenir de prendre en charge PGP sur d'autres canaux que le courrier électronique uniquement. Garder cela à l'esprit garantira que le backend et l'API que nous concevons seront faciles à tester et à intégrer. Suite à ma proposition (ouverte à la discussion):

Il devrait y avoir une classe appelée PgpMessage située dans le fichier lib/pgp_message.rb . Cette classe prend un argument obligatoire qui sera (éventuellement) la chaîne de message chiffrée/le contenu de l'e-mail. Exemple:

instance = PgpMessage.new(email_content)

L'instance doit fournir l'interface suivante :

• #signé?
• #vérifié ? (signature) # la signature est facultative et peut être une signature externe provenant, par exemple, d'une pièce jointe
• #signature_error
• #crypté ?
• #décrytable ?
• #déchiffré
• #clé
• #erreur de décryptage
• #encrypt( clé(s)_publique(s) )
• #signe

Interface PGP

Pour être honnête, je n'ai trouvé aucun joyau que j'aime avoir comme dépendance. Ils semblent tous non maintenus, complexes ou nécessitent une compilation d'extensions en C. Cela vaut peut-être la peine d'essayer si nous ne pouvons pas simplement accéder à la CLI PGP. Qu'en penses-tu?

Intégration de PgpMessage dans le Postmaster :: PreFilter pour le déchiffrement

La classe PgpMessage peut ensuite être utilisée dans le Postmaster::PreFilter pour initialiser une instance et vérifier la pertinence du message. S'il s'agit d'un message crypté PGP, nous pouvons utiliser les autres méthodes pour extraire les données dont nous avons besoin et écraser le contenu pour body et attachments dans le hachage mail donné.
De plus, nous devons stocker des méta-informations (comme vous l'avez déjà indiqué) dans l'article qui sera créé en définissant l'en-tête x-zammad-article-preferences :

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

Je pense que les métadonnées suivantes devraient suffire :

• decryption_key <- clé
• decryption_error <- decryption_error (en cas d'existence)
• message_crypté <- mail['body']
• signature_status <- vérifié ?
• signature_error <- signature_error (en cas d'existence)

variations prises en charge des messages déchiffrables

La classe PgpMessage devrait être capable de gérer (au moins ?) les combinaisons et variations suivantes de messages PGP entrants :

• crypté
• signé
• crypté + signé
• en ligne
• attachement

Avez-vous déjà suffisamment d'exemples d'e-mails ?

Nous devons avoir une liste complète de cas de test pour couvrir divers cas qui peuvent être étendus facilement à l'avenir.

envoyer des messages cryptés

Étant donné que Zammad ne prend en charge que l'envoi d'e-mails HTML , nous n'avons qu'à couvrir l'envoi d'e-mails PGP detached .

L'endroit où Zammad construit un e-mail à partir d'attributs donnés se trouve dans app/models/channel/email_build.rb dans la méthode self.build . Cela devrait être étendu pour utiliser la classe PgpMessage pour créer une instance avec l'attribut body donné et utiliser les méthodes encrypted et signed pour créer le chiffrement PGP et le contenu du corps et les pièces jointes signés.
Pour ce faire, il est nécessaire de rechercher les clés publiques des adresses e-mail des destinataires. La façon dont les utilisateurs peuvent stocker leur clé (dans leur profil) n'est pas encore claire. J'en discuterai en interne et vous tiendrai au courant.

Je pense qu'il ne devrait pas y avoir d'option pour envoyer des e-mails non cryptés une fois que PGP est configuré et que le destinataire le prend en charge. Nous devons clarifier cela, mais jusque-là, cela devrait être la voie à suivre.

Interface d'administration

Cela devrait être isolé de la fonctionnalité de base et sera décrit plus tard. Je pense que vous aurez besoin de notre soutien. J'en discuterai en interne et vous ferai savoir comment nous l'abordons.

Conclusion

Cela devrait être suffisant maintenant et pointer dans la bonne direction. Nous atteindrons probablement certains points où nous devrons nous réaligner et couvrir d'autres cas, mais laissez-les surgir en premier.
N'hésitez pas à poser des questions si elles se présentent.

J'ai hâte de voir et de revoir vos modifications 🤓

Merci pour votre soutien 🚀
Thorsten

Pour être honnête, je n'ai trouvé aucun joyau que j'aime avoir comme dépendance. Ils semblent tous non maintenus, complexes ou nécessitent une compilation d'extensions en C. Cela vaut peut-être la peine d'essayer si nous ne pouvons pas simplement accéder à la CLI PGP. Qu'en penses-tu?

La CLI PGP n'est pas stable et ne devrait pas, selon GPG, être utilisée comme API. J'ai eu du succès avec l'utilisation de ruby-gpgme jusqu'à présent, c'est donc la voie que j'aimerais suivre pour l'instant. Étant donné que pour autant que je sache, GPG n'a pas d'API, mais uniquement des bibliothèques de niveau C, je ne pense pas que nous nous en sortirons sans aucune extension C .. sauf pour une réimplémentation de GPG en ruby ​​peut-être, mais Je n'en connais aucun.

Merci d'avoir été clair. Je n'étais pas au courant de cela. Cela me semble bon alors. C'est un peu inquiétant que leurs versions échouent, mais je vais y jeter un œil.

Salut! Comme indiqué précédemment, ce problème a commencé par une demande de fonctionnalité PGP. Plus tard, nous avons également ajouté S/MIME. Mais comme les deux sont implémentés indépendamment et sont des technologies différentes, nous avons décidé de déplacer l'exigence S/MIME vers la nouvelle version #1961. N'hésitez pas à vous inscrire là-bas si vous êtes intéressé par des progrès. Les discussions doivent être reportées au conseil d'administration de la communauté pour éviter le bruit sur le suivi des problèmes. Merci!

Par conséquent, je vous fournirai un assistant RSpec pour faciliter les tests et vous aider du mieux que je peux. Je l'ajouterai à la branche de développement dans les prochains jours.

@thorsteneckel a-t-il déjà atterri et si oui, où est-il exactement ? :)

@luto - désolé pour le retard - le voici : https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Il vous suffit de placer un *filter_filename*_spec.rb dans spec/models/channel/filter/ (comme pour models/channel/filter/follow_up_merged.rb et d'ajouter , type: :channel_filter après le nom de votre classe de filtre.
Après cela, vous avez deux assistants disponibles :

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

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

Le paramètre nommé channel est facultatif et ne devrait pas être nécessaire dans votre cas.

Merci!
Pour info : la branche vit maintenant dans notre fork . n'hésitez pas à commenter l'un des commits au fur et à mesure. Cela devrait garder l'examen final facile et court pour toutes les personnes impliquées :)

Salut @luto - super de te voir travailler là-dessus avec un tel rythme. J'ai remarqué que le code ne semble pas avoir été vérifié avec rubocop. Nous utilisons rubocop et coffeelint pour garantir le guide de style Zammad pour les deux types de fichiers. Il existe même une configuration de filtre pré-commit disponible si vous souhaitez effectuer les vérifications automatiquement. Faites-moi savoir si je peux vous donner plus d'informations à ce sujet.

Oh, bien sûr. J'ai installé le hook avec pre-commit install ainsi que l' extension correspondante pour mon éditeur . L'indentation a été corrigée via filter-branch , donc l'historique est plus beau ; toutes les autres infractions ont été fixées à la main. Le flic est plutôt content maintenant :)

Vous remarquerez peut-être un avec des pythonismes dans le code. Bien que j'essaie d'imiter la façon dont Ruby fait les choses du mieux que je peux, je suis toujours un gars python de métier;) S'il vous plaît, signalez simplement les choses, si elles vous semblent en arrière. Rubocop en a attrapé pas mal :sweat_smile:

Agréable! Je viens de remarquer qu'il y a au moins un type de modifications appliquées qui ne correspondent pas à notre configuration rubocop : Utilisation unless au lieu de if s négatifs. Il semble donc que votre rubocop en fasse trop ici.

Oh les pythonismes me conviennent parfaitement. Rien à redire pour l'instant 🤓

Salut @luto - Je voulais juste jeter un œil sur l'état actuel du développement mais j'ai remarqué qu'il n'y avait pas eu de commit depuis 24 jours. Y a-t'il quelque chose que je puisse faire?

Y a-t'il quelque chose que je puisse faire?

réparer nos autres projets internes :wink: :grin:
Il n'y a pas de bloqueur dans l'enceinte de Zammad, juste un manque de temps général. Les travaux devraient se poursuivre la semaine prochaine.

@thorsteneckel J'ai en quelque sorte rencontré un problème. Gpg (ou du moins gpgme) ne fait pas de distinction entre "le courrier électronique est chiffré, mais ne peut pas être déchiffré" et "le courrier électronique est chiffré et tout va bien" dans la plupart des cas. Ce comportement n'est pas compatible avec les méthodes encrypted? et decryptable? décrites précédemment. En ce moment, j'ai un certain nombre de hacks pour détecter les mails chiffrés, mais pas déchiffrables, mais je n'arrive pas à le faire fonctionner dans tous les cas.

Que pensez-vous de ne pas faire de distinction entre décryptable et crypté dans l'interface utilisateur ? Sauf dans des cas évidents comme un en-tête de message GPG manquant, ofc.

Quand peut-on s'attendre à la mise en œuvre et à l'intégration dans Zammad ? La mise en œuvre est-elle prévue pour une version spécifique ?

Des nouvelles?

J'ai le sentiment que ceux qui pourraient faire avancer le développement de ce plugin ont autre chose en tête que de vérifier les réponses à ce problème.
Si vous souhaitez attirer leur attention à ce sujet, vous pouvez leur écrire un e-mail : [email protected] - je l'ai déjà fait - ou leur envoyer un tweet amical @ubernauten

@hatscher désolé pour le retard ; comme @0xErnie a deviné que j'ai actuellement d'autres choses à faire, mais cette fonctionnalité est toujours sur notre radar. Veuillez noter que je travaille actuellement sur ce solo, pas dans le cadre de l'équipe de Zammad, Inc. et sans aucune fondation externe. Cela peut donc prendre un certain temps.

En ce qui concerne les bloqueurs, il y a une question pour @thorsteneckel ouverte ici, ainsi qu'une question privée sur la façon dont nous allons aborder le composant de l'interface utilisateur. N'hésitez pas à le contacter, si vous souhaitez participer pour faire avancer les choses, @hatscher ! Le principal obstacle est mon manque de temps, cependant.

Désolé pour la réponse tardive, surtout pour toi @luto ! Je ne peux pas lui donner le temps et l'attention dont il a besoin actuellement. Je prévois de régler ce problème dans 2 semaines à partir de maintenant.

Des nouvelles? Nous avons besoin de cette fonctionnalité...

@hatscher beaucoup d'entre nous en ont besoin :) Mais après tout, tous ceux qui travaillent sur la fonctionnalité (@luto) le font volontairement :) S'il y a un réel besoin commercial, je suppose que faire un don (soit de la pâte ou du travail) aiderait à conduire avancer le progrès. Malheureusement je n'ai pas le temps de contribuer, il ne me reste donc que de l'espoir et de la patience :P

Parlons des contributions : que diriez-vous de soumettre l'état actuel du développement en tant que relations publiques afin que d'autres puissent se joindre s'ils sentent qu'ils pourraient contribuer ?

Étant donné le triste état des API GPG à la fois en ruby ​​et en général, la nouvelle implémentation de GPG rust pourrait valoir le coup d'œil.

Avec un grain de sel:

FIXATIONS BIENTÔT DISPONIBLES !

Y a-t-il des nouvelles concernant l'intégration PGP et S/MIME ? Je voudrais également faire un don car j'ai un besoin urgent de cette fonctionnalité.

Existe-t-il réellement une liste avec les fonctionnalités prévues des prochaines versions ?

Salut @hatscher ,
nous avons également besoin de S/MIME et sommes en pourparlers avec Zammad sur les coûts. Voulons-nous nous parler pour peut-être partager les coûts d'intégration? Peut-être qu'il suffit de m'envoyer un e-mail (prénom et nom de).

La messagerie est en route ;-)

Nous recherchons actuellement d'autres personnes qui sont prêtes à financer cette fonctionnalité (peut-être aussi avec le cryptage S/MIME en tant que package). S'il vous plaît contactez-moi si vous êtes intéressé par mon prénom à lastname .de. Je vais vérifier et voir combien de personnes volontaires sont là pour que nous puissions simplement partager les coûts.

@martinseener C'est formidable d'apprendre que vous avez essayé d'obtenir un financement pour cette fonctionnalité. Pourriez-vous partager les progrès réalisés ou les problèmes rencontrés ? Le support PGP est actuellement en train de prendre ou de casser une décision concernant un déménagement vers Zammad, donc toute idée serait appréciée.

Désolé, mais pour le moment, nous ne pouvons partager aucune information sur ce sujet.
Nous mettrons à jour ce problème en conséquence dès que quelque chose bougera pour le Zammad-Core.

En regardant votre temps de réponse de plusieurs mois et les discussions précédentes sur cette question, je conclus que l'ajout du support PGP à Zammad n'est pas une priorité pour vous ou ne se produira pas du tout. (Je résume juste ici pour tous ceux qui viennent dans le futur et ne veulent pas lire toute la discussion.)

Salut @rixx - tu as raison. Nous travaillons actuellement sur des tâches basées sur notre schéma de priorité :

1er : support / développement sur mesure
Ce sont les personnes qui financent Zammad et les fonctionnalités que nous publions. Zammad ne serait pas là aujourd'hui sans eux. Les avoir signifie vraiment beaucoup pour nous et nous encourage à être sur la bonne voie.

2e : 80 % de fonctionnalités/problèmes
Le temps libre que nous gagnons grâce au support de nos clients est consacré à 100% au produit. Il est important pour nous d'être équitable envers tout utilisateur de notre base d'utilisateurs. Cependant, dès qu'il s'agit de détails, nous devons prendre de plus en plus de décisions en faveur d'une partie par rapport à l'autre. Par conséquent, nous ne travaillons que sur les fonctionnalités et les problèmes qui affectent 80 % de notre base d'utilisateurs. De cette façon, nous pouvons nous assurer que la majorité de notre base d'utilisateurs profite des changements que nous introduisons.

3ème : Intérêt personnel
Chez Zammad, chacun est libre de consacrer du temps à des tâches qui l'intéressent personnellement. Si vous jetez un coup d'œil, vous remarquerez que nous répondons aux problèmes et aux questions qui ne relèvent pas de la catégorie des changements financés ou les plus pertinents. C'est parce que nous nous soucions réellement et aimons aider les gens. Cependant, ce sont pour la plupart des tâches plus petites car le temps libre est actuellement très limité - malheureusement.

Revenons maintenant au sujet : PGP n'entre actuellement dans aucune des catégories répertoriées ci-dessus. C'est pourquoi vous avez raison de dire que ce n'est actuellement pas une priorité pour nous. Cependant, vous vous trompez lorsque vous dites que PGP ne se produira pas du tout. PGP a une priorité relativement élevée pour nous, c'est en fait sur notre projet interne pour la feuille de route publique qui ne comprend que les changements les plus pertinents.
Donc le temps pour PGP n'est pas encore venu mais il le sera sûrement. Selon le schéma de priorité - tôt ou tard.
Ce qui me manque dans votre résumé, c'est le fait que le développement de PGP a déjà commencé en tant qu'effort communautaire par @luto avec notre soutien (merci encore @luto !). Malheureusement, la priorité a changé et le changement est actuellement obsolète. Cependant, tous ceux qui ont les connaissances et la capacité de ramasser les choses et de continuer à travailler dessus seront assurément soutenus par nous !

Il y a aussi des nouvelles pour tous ceux qui s'intéressent au sujet général de la communication cryptée : les gens formidables autour de @martinseener à barzahlen.de ont financé le développement de la communication S/MIME (#1961) - qui sera bientôt lancée.

Si vous souhaitez approfondir cette discussion ou même contribuer, n'hésitez pas à ouvrir un fil de discussion ou à me contacter par MP sur le forum de la communauté et à garder ce problème sur le sujet.

Des nouvelles de la "communication S/MIME" ?

Si vous devez demander, veuillez au moins utiliser le bon endroit : https://github.com/zammad/zammad/issues/1961

Désolé, en raison des commentaires manquants au cours des derniers mois, je limite ce problème aux contributeurs uniquement.
Cela permet de réduire le bruit et nous aide à nous concentrer sur les problèmes.

Si nous avons des mises à jour à ce sujet, nous mettrons à jour ce problème en conséquence.

Comme vous l'avez peut-être vu au #1961, nous avons ajouté le support S/MIME et le publierons avec la prochaine version 3.4 de Zammad 🎉 Un grand merci à @martinseener sur barzahlen.de pour l'avoir parrainé et donc rendu cela possible 🙌
Malheureusement, nous n'avons toujours pas les ressources nécessaires pour ajouter la prise en charge de PGP. Nous pensions tester certaines choses, mais nous n'en avons pas encore eu l'occasion. C'est pourquoi je voulais vous donner une courte mise à jour ici.
Cependant, l'intégration S/MIME fournit un "cadre" presque complet pour gérer le courrier sécurisé et une belle implémentation de référence sur la façon dont les choses doivent être intégrées/construites. Il y a toujours l'excellent travail initial effectué par @luto au fork d' Uberspace . Si quelqu'un est prêt à tenter sa chance, nous sommes heureux de vous aider avec tout ce que nous pouvons. Ouvrez simplement un fil de discussion sur le forum communautaire et mentionnez-moi.

Nous vous tenons au courant dès que de nouvelles informations sont disponibles - promis ✌️