Zammad: PGP

+1 für S/MIME-Unterstützung

Okay, ich habe den Titel geändert. Am besten wäre es natürlich, wenn es beides bieten würde.

Ich würde mich über die Möglichkeit freuen X.509 verschlüsselte Mails zu senden und zu empfangen.

JA, es wäre sehr schön, mit X.509 signierte oder verschlüsselte Mails senden und empfangen zu können.

X.509-verschlüsselte Mails sind also S/MIME-Mails. Ich persönlich würde mir PGP mehr wünschen (auch weil es weiter verbreitet ist), aber in dieser Ausgabe geht es um beide Systeme. 😃

Ich würde verschlüsselte Benachrichtigungen zur Wunschliste hinzufügen - daher müssen Benutzer in der Lage sein, ihren öffentlichen Schlüssel zu ihrem Profil hinzuzufügen.

FYI: Ein nettes Plugin mit einer solchen Funktionalität existiert für Redmine: https://github.com/C3S/redmine_openpgp

Dieses Juwel scheint nicht wirklich gewartet zu werden (letztes Commit ), aber es gibt mehrere andere . Persönlich würde ich sagen, dass dieses Juwel den neuesten Commit hat.

Heute hatten wir die erste Kundenanfrage nach PGP-Support, da sie ihre Bankdaten nicht über eine unverschlüsselte Verbindung abfragen wollte. Dafür +1

+1.
Wir arbeiten mit der IT-SEC-Community zusammen und erhalten Tonnen von PGP-verschlüsselten E-Mails, die wir in Zammad nicht öffnen können, also müssen wir exportieren und entschlüsseln, es ist ein höllischer Arbeitsablauf. +1 für die Unterstützung von PGP und vielleicht S/MIME-Mails in Zammad :)

Heutzutage ist E-Mail-Verschlüsselung ein Muss. Die Datenschutz-Grundverordnung (DSGVO) fordert Privacy by Design and by Default und nach dem Stand der Technik.

Technisch könnte dies durch die Integration der p≡p-Engine (ziemlich einfache Privatsphäre) leicht zu lösen sein.

+1
Wir erhalten oft verschlüsselte Mails. Das Exportieren und manuelle Entschlüsseln von verschlüsselten Tickets ist mühsam, und dann können wir nicht einmal über das Ticketsystem auf Tickets antworten.

+1
Ohne PGP/GPG kann ich nicht von OTRS zu Zammad migrieren. Ich habe viele verschlüsselte Tickets mit gnupg in meinem alten OTRS.

+1

Wir möchten, dass GnuPG alle ausgehenden Ticket-E-Mails signiert , nachdem in einem sehr hässlichen Fall unsere E-Mail gefälscht wurde, um unsere Kunden auszurauben.

Vielleicht könnte PeP integriert werden, da es eine einfache und brauchbare Lösung für die PGP-Verschlüsselung ist.

Ich denke auch, dass es eine großartige Funktion wäre, signierte E-Mails zu senden. Dies würde dem Empfänger ein gewisses Maß an Vertrauen geben, dass die Adresse echt und vertrauenswürdig ist.

Der nächste Schritt wäre, die Nachricht vollständig zu verschlüsseln.

@martini @monotek wir denken darüber nach, den GPG-Teil davon selbst in Angriff zu nehmen, intern. Gibt es Einschränkungen, wenn wir dies zusammenführen, wenn wir dies tun? Gibt es Funktionen, die Sie sehen möchten oder benötigen?

Hallo @luto - hört sich gut an! Dinge, die für eine Zusammenführung erforderlich sind, sind:

• Tests, vorzugsweise RSpec
• Dokumentation
• Code-API-Dokumentation
• QAd-Code über unsere Rubocop- und Coffeelint-Konfiguration

Wir haben uns bereits einige Ruby-Gems angesehen, die eine API für die gpg-CLI-Binärdatei bereitstellen. Soweit ich mich erinnere, sah keiner von ihnen wirklich vielversprechend aus. Bitte stellen Sie sicher, dass Sie sich nur auf gepflegte/Qualitätsabhängigkeiten verlassen, da dies ein kritischer Punkt ist.
Eine benutzerdefinierte Implementierung ist möglich, aber denken Sie an Erweiterbarkeit und Wartung. Legen Sie nicht die gesamte Logik in das Modul, sondern erstellen Sie eine lib-Klasse dafür. Respektieren Sie das Prinzip der Einzelverantwortung.

Die Funktionalität sollte alle Variationen des Signierens, Verifizierens und Ver-/Entschlüsselns des Sendens und Empfangens von Mails beinhalten 🤓
Die Behandlung eingehender Nachrichten sollte so früh wie möglich erfolgen, damit der Inhalt in anderen Komponenten verfügbar ist.
Die Behandlung ausgehender Nachrichten sollte so spät wie möglich erfolgen, um auf die Inhalte in anderen Komponenten zugreifen zu können.

Es sollte eine nette Admin-Oberfläche geben, um öffentliche und private Schlüssel zu verwalten.

Zögern Sie nicht, uns unter [email protected] zu kontaktieren, um Ihre Fragen zu stellen und unsere Unterstützung zu erhalten. Wir freuen uns sehr über Ihren 💪 Let's do it the Zammad way 🏎

Wir haben auch den ersten Kunden, der eine solche Kommunikation benötigt, also stimme ich auch für diese. Gibt es schon Fortschritte? Ich würde auch gerne beim Testen einer Beta helfen.

@martinseener Afaik, das steht nicht auf der Roadmap des Zammad-Teams. Wir planen derzeit, dies in Eigenregie umzusetzen. Wenn Sie etwas tun möchten, damit wir es schneller erledigen können und Sie Ihren Kunden bedienen können, wenden Sie sich bitte über die E-Mail-Adresse in meinem Github-Profil an uns.

@thorsteneckel Ich prototypiere derzeit eine Implementierung zum Empfangen von Mails in zwei Teilen:

1. entschlüsseln Sie die Mail in Postmaster::PreFilter : setzen Sie die entschlüsselte Nachricht als Inhalt; Original wegwerfen; Speichern Sie den verwendeten Entschlüsselungsschlüssel in den Metadaten
2. in Postmaster::PostFilter erstelle ein GpgCryptoInfo Objekt, hänge es an Article an; Informationen wie den verwendeten Entschlüsselungsschlüssel und den Signaturstatus dauerhaft speichern

Einige Fragen:

• Denken Sie, dass dies mit diesen Filter-APIs implementiert werden sollte? Oder sollte dies in Channel::EmailParser fest codiert sein?
• Gibt es Postmaster::PreFilter Abonnenten, die Zugriff auf entschlüsselte Nachrichteninhalte benötigen? In diesem Fall wird eine fest codierte Implementierung oder ein Postmaster::EarlyPreFilter benötigt.
• Gibt es Informationen außer dem verwendeten Schlüssel zum Verschlüsseln/Entschlüsseln/Signieren/Verifizieren sowie dem Signaturstatus der empfangenen E-Mails, die Sie dauerhaft gespeichert sehen möchten?

Außerdem eine allgemeine Frage: EmailParser oder die Filter scheinen der perfekte Ort zu sein, um Mails zu _entschlüsseln_; Können Sie sich einen "perfekten" Ort vorstellen, um sie zu verschlüsseln?

Ich hoffe, dass diese Ausgabe der richtige Ort ist, um Fragen zur Umsetzung zu stellen. Wenn nicht, verweise mich bitte auf einen anderen, vorzugsweise öffentlichen :) Danke!

Hi @luto - Ich schreibe gerade meine Gedanken dazu auf. Da es sich um ein ziemlich großes und wichtiges Thema handelt, dauert es einige Zeit. Ich versuche bis Ende der Woche fertig zu werden. Danke für dein Verständnis.

Kleines Update: Postmaster::PreFilter Filter sind bestellt. Ich habe meine derzeit direkt nach IdentifySender platziert, damit ich herausfinden kann, welche gpg-Schlüssel ich ausprobieren soll. Wenn ich das weiß, scheinen die Filter für mich der richtige Ort zum Entschlüsseln zu sein.

@thorsteneckel Danke, dass du dir die Zeit genommen hast! Freue mich auf deine Zuschrift. :)

Hallo @luto , das freut mich zu hören! Ich hätte gerne die von Ihnen vorgeschlagene Koordinierung in dieser Angelegenheit. So wird es transparent und wir können die geteilten Informationen für eine technische Dokumentation wiederverwenden. Sie können auf dieses Problem in Ihrem Arbeitszweig Ihres Forks verweisen und es wird hier verwiesen. Bitte erstellen Sie einen Pull-Request, nachdem die Änderungen abgeschlossen sind. In der Zwischenzeit werde ich Ihren Zweig überprüfen und die Änderungen sehen.
Wir sollten die S/MIME-Funktionalität in ein separates Thema verschieben, da wir sie jetzt nicht implementieren werden.

Zu deinen Fragen: Du bist auf dem absolut richtigen Weg. Ich werde einige Dinge aufschreiben und Ihre Fragen auf dem Weg beantworten.

Allgemeine Entwicklung

Unserer Erfahrung nach eignet sich testgetriebene Entwicklung (mit RSpec) am besten für diese Art von Aufgaben. Es liegt an Ihnen, wie Sie es angehen, aber wir benötigen definitiv eine umfassende Testsuite für die Funktionalität. Deshalb werde ich Ihnen einen RSpec-Helfer zur Verfügung stellen, um das Testen zu erleichtern und Sie auf dem Weg so gut wie möglich zu unterstützen. Ich werde es in den nächsten Tagen zu develop hinzufügen. Sie sollten diesen Zweig als Basis verwenden, da er auch unser Arbeitszweig ist. Es wird in der Zukunft mit Master zusammengeführt und Stable ersetzen.

Postmaster::Vorfilter

Postmaster::PreFilter s sind der richtige Ort. Sie können den Zeitpunkt der Ausführung durch ein Zahlenpräfix im Namen der Filterregistrierung beeinflussen. Niedrigere Nummern werden früher ausgeführt .
Für bereits initialisierte Systeme ist ebenfalls eine Migration erforderlich, die die Einstellung hinzufügt .
Ich würde einen Namen wie app/models/channel/filter/decrypt.rb vorschlagen - aber am Ende liegt es an Ihnen.

Nachdem die Registrierung abgeschlossen ist, führt Zammad den Filter für jede eingehende E-Mail aus.

PGP-Nachrichtenklasse

Da wir an dieser Stelle nur PGP implementieren werden, müssen wir sicherstellen, dass wir später keine Hindernisse für das Hinzufügen von S/MIME hinzufügen. Zusätzlich könnte es in Zukunft erforderlich sein, PGP auf anderen Kanälen als nur E-Mail zu unterstützen. Wenn Sie dies im Hinterkopf behalten, wird sichergestellt, dass das von uns entworfene Backend und die API einfach zu testen und zu integrieren sind. Nach meinem Vorschlag (zur Diskussion offen):

Es sollte eine Klasse namens PgpMessage in der Datei lib/pgp_message.rb . Diese Klasse nimmt ein erforderliches Argument entgegen, das der (möglicherweise) verschlüsselte Nachrichtenstring/E-Mail-Inhalt sein wird. Beispiel:

instance = PgpMessage.new(email_content)

Die Instanz sollte die folgende Schnittstelle bereitstellen:

• #unterzeichnet?
• #verified?(Signatur) #Signatur ist optional und kann eine externe Signatur aus zB einem Anhang sein
• #signature_error
• #verschlüsselt?
• #entschlüsselbar?
• #entschlüsselt
• #Schlüssel
• #Dekodierungsfehler
• #encrypt( öffentliche_Schlüssel(e) )
• #Unterschrift

PGP-Schnittstelle

Um ehrlich zu sein, habe ich kein Juwel gefunden, das ich gerne als Abhängigkeit hätte. Sie sehen alle ungepflegt, komplex aus oder benötigen eine C-Kompilierung von Erweiterungen. Es könnte einen Versuch wert sein, wenn wir nicht einfach auf die PGP-CLI zugreifen können. Was denkst du?

PgpMessage-Integration in den Postmaster::PreFilter zur Entschlüsselung

Die PgpMessage-Klasse kann dann in Postmaster::PreFilter verwendet werden, um eine Instanz zu initialisieren und die Nachricht auf Relevanz zu prüfen. Wenn es sich um eine PGP-verschlüsselte Nachricht handelt, können wir mit den anderen Methoden fortfahren, um die benötigten Daten zu extrahieren und den Inhalt für body und attachments im angegebenen mail -Hash zu überschreiben.
Zusätzlich müssen wir einige Meta-Informationen (wie Sie bereits gesagt haben) in dem Artikel speichern, der durch das Setzen des x-zammad-article-preferences -Headers erstellt wird:

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

Ich denke, die folgenden Metadaten sollten ausreichen:

• Entschlüsselungsschlüssel <- Schlüssel
• decryption_error <- decryption_error (falls vorhanden)
• verschlüsselte_nachricht <- mail['body']
• signature_status <- verifiziert?
• signature_error <- signature_error (falls vorhanden)

unterstützte Variationen von entschlüsselbaren Nachrichten

Die PgpMessage-Klasse sollte (mindestens?) die folgenden Kombinationen und Variationen eingehender PGP-Nachrichten verarbeiten können:

• verschlüsselt
• unterzeichnet
• verschlüsselt + signiert
• im Einklang
• Anhang

Haben Sie schon genug Beispielmails?

Wir brauchen eine umfassende Liste von Testfällen, um verschiedene Fälle abzudecken, die in Zukunft einfach erweitert werden können.

Versenden von verschlüsselten Nachrichten

Da Zammad nur das Senden von HTML-E-Mails unterstützt, müssen wir nur das Senden detached PGP-Mails abdecken.

Der Ort, an dem Zammad eine E-Mail aus gegebenen Attributen erstellt, befindet sich in app/models/channel/email_build.rb in der Methode self.build . Dies sollte erweitert werden, um die Klasse PgpMessage zu verwenden, um eine Instanz mit dem gegebenen Attribut body zu erstellen und die Methoden encrypted und signed zu verwenden, um die PGP-Verschlüsselung zu erstellen und signierte Textinhalte und Anhänge.
Dazu ist es erforderlich, die öffentlichen Schlüssel der E-Mail-Adressen der Empfänger nachzuschlagen. Wie die Benutzer ihren Schlüssel (in ihrem Profil) speichern können, ist noch nicht klar. Ich werde das intern besprechen und Ihnen Bescheid geben.

Ich denke, dass es keine Möglichkeit geben sollte, unverschlüsselte Mails zu senden, sobald PGP konfiguriert ist und der Empfänger dies unterstützt. Wir müssen das klären, aber bis dahin sollte dies der richtige Weg sein.

Admin-Oberfläche

Dies sollte von der Kernfunktionalität isoliert werden und wird später beschrieben. Ich denke, Sie werden unsere Unterstützung brauchen. Ich werde es intern besprechen und Sie wissen lassen, wie wir es angehen.

Fazit

Das sollte jetzt ausreichen und in die richtige Richtung weisen. Wir werden wahrscheinlich einige Stellen erreichen, an denen wir uns neu ausrichten und andere Fälle abdecken müssen, aber sie zuerst entstehen lassen.
Fühlen Sie sich frei, Fragen zu stellen, wenn sie auftreten.

Ich freue mich darauf, Ihre Änderungen zu sehen und zu überprüfen 🤓

Danke für deine Unterstützung 🚀
Torsten

Um ehrlich zu sein, habe ich kein Juwel gefunden, das ich gerne als Abhängigkeit hätte. Sie sehen alle ungepflegt, komplex aus oder benötigen eine C-Kompilierung von Erweiterungen. Es könnte einen Versuch wert sein, wenn wir nicht einfach auf die PGP-CLI zugreifen können. Was denkst du?

Die PGP-CLI ist nicht stabil und sollte laut GPG nicht als API verwendet werden. Ich hatte bisher Erfolg mit der Verwendung von ruby-gpgme , also möchte ich diesem Weg jetzt folgen. Angesichts der Tatsache, dass GPG meines Wissens keine API hat, sondern nur C-Level-Bibliotheken, glaube ich nicht, dass wir ohne C-Erweiterungen davonkommen werden ... außer vielleicht einer Neuimplementierung von GPG in Ruby, aber Ich kenne keine.

Danke für die Klarstellung. Das war mir nicht bewusst. Klingt dann gut für mich. Es ist ein bisschen besorgniserregend, dass ihre Builds fehlschlagen, aber ich werde es mir ansehen.

Sie da! Wie bereits erwähnt, begann dieses Problem mit einer Anfrage für die PGP-Funktionalität. Später haben wir auch S/MIME hinzugefügt. Da beide unabhängig voneinander implementiert werden und unterschiedliche Technologien sind, haben wir uns entschieden, die S/MIME-Anforderung in die neue Ausgabe Nr. 1961 zu verschieben. Fühlen Sie sich frei, sich dort zu abonnieren, wenn Sie an Fortschritten interessiert sind. Diskussionen sollten im Community Board geführt werden, um Lärm im Issue Tracker zu vermeiden. Danke!

Deshalb werde ich Ihnen einen RSpec-Helfer zur Verfügung stellen, um das Testen zu erleichtern und Sie auf dem Weg so gut wie möglich zu unterstützen. Ich werde es in den nächsten Tagen in den Entwicklungszweig aufnehmen.

@thorsteneckel ist das schon gelandet und wenn ja, wo genau ist das? :)

@luto - Entschuldigung für die Verzögerung - hier ist es: https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Sie müssen nur ein *filter_filename*_spec.rb in spec/models/channel/filter/ platzieren (wie bei models/channel/filter/follow_up_merged.rb und , type: :channel_filter nach dem Namen Ihrer Filterklasse hinzufügen.
Danach stehen Ihnen zwei Helfer zur Verfügung:

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

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

Der benannte Parameter channel ist optional und sollte in Ihrem Fall nicht benötigt werden.

Danke!
FYI: Der Zweig lebt jetzt in unserer Gabelung . Fühlen Sie sich frei, einen der Commits zu kommentieren, während ich gehe. Das sollte die abschließende Bewertung für alle Beteiligten einfach und kurz halten :)

Hallo @luto – toll zu sehen, dass du so schnell daran arbeitest. Mir ist aufgefallen, dass der Code nicht so aussieht, als wäre er mit rubocop geprüft worden. Wir verwenden rubocop und coffeelint, um den Zammad-Styleguide für beide Arten von Dateien sicherzustellen. Es ist sogar eine Pre-Commit-Filterkonfiguration verfügbar, wenn Sie die Überprüfungen automatisch durchführen möchten. Lassen Sie mich wissen, wenn ich Ihnen dazu mehr Informationen geben kann.

Ach, sicher. Ich habe den Hook mit pre-commit install sowie die passende Erweiterung für meinen Editor installiert. Die Einrückung wurde über filter-branch korrigiert, damit der Verlauf besser aussieht; Alle anderen Verstöße wurden von Hand behoben. Der Cop ist jetzt meistens glücklich :)

Möglicherweise bemerken Sie ein mit Pythonismen im Code. Während ich versuche, die Ruby-Methode so gut wie möglich nachzuahmen, bin ich immer noch ein Python-Typ von Beruf ;) Bitte weisen Sie einfach auf Dinge hin, wenn sie Ihnen rückwärts erscheinen. Rubocop hat einige davon erwischt :sweat_smile:

Schön! Mir ist gerade aufgefallen, dass mindestens eine Art von Änderungen angewendet wird , die nicht mit unserer Rubocop-Konfiguration übereinstimmen: Verwendung unless anstelle von negativen if s. Es scheint also, dass Ihr Rubocop hier zu viel tut.

Oh, die Pythonismen sind genau richtig für mich. Bisher nichts zu meckern 🤓

Hi @luto - ich wollte mir nur mal den aktuellen Stand der Entwicklung ansehen, habe aber festgestellt, dass es seit 24 Tagen keinen Commit gab. Kann ich irgendetwas tun?

Kann ich irgendetwas tun?

unsere anderen internen Projekte reparieren :wink: :grin:
Es gibt keinen Blocker innerhalb der Grenzen von Zammad, nur einen allgemeinen Zeitmangel. Die Arbeiten daran sollen nächste Woche fortgesetzt werden.

@thorsteneckel Ich bin irgendwie auf einen Haken gestoßen. Gpg (oder zumindest gpgme) unterscheidet in den meisten Fällen nicht zwischen „E-Mail ist verschlüsselt, kann aber nicht entschlüsseln“ und „E-Mail ist verschlüsselt und alles ist gut“. Dieses Verhalten ist mit den zuvor beschriebenen Methoden encrypted? und decryptable? nicht kompatibel. Im Moment habe ich eine Reihe von Hacks, um verschlüsselte, aber nicht entschlüsselbare Mails zu erkennen, aber ich kann es nicht in allen Fällen zum Laufen bringen.

Was halten Sie davon, in der Benutzeroberfläche nicht zwischen entschlüsselbar und verschlüsselt zu unterscheiden? Abgesehen von offensichtlichen Fällen wie einem fehlenden GPG-Nachrichtenheader, ofc.

Wann können wir mit der Implementierung und Integration in Zammad rechnen? Ist die Implementierung für ein bestimmtes Release geplant?

Irgendwelche Neuigkeiten?

Ich habe das Gefühl, dass diejenigen, die die Entwicklung dieses Plugins vorantreiben könnten, andere Dinge im Kopf haben, als die Antworten zu diesem Thema zu überprüfen.
Wenn du sie darauf aufmerksam machen möchtest, kannst du ihnen eine E-Mail schreiben: [email protected] - das habe ich bereits getan - oder ihnen einen freundlichen Tweet an @ubernauten schicken

@hatscher Entschuldigung für die Verspätung; Wie @0xErnie vermutet hat, habe ich derzeit andere Dinge zu tun, aber dieses Feature ist immer noch auf unserem Radar. Bitte beachten Sie, dass ich derzeit an diesem Solo arbeite, nicht als Teil des Zammad, Inc.-Teams und ohne externe Gründung. Das kann also eine Weile dauern.

Was Blocker betrifft, gibt es hier eine offene Frage für @thorsteneckel sowie eine private darüber, wie wir die UI-Komponente davon angehen werden. Fühlen Sie sich frei, ihn zu kontaktieren, wenn Sie sich einbringen möchten, um dies voranzutreiben, @hatscher! Der Hauptblocker ist jedoch mein Zeitmangel.

Sorry für die späte Antwort, besonders an dich @luto ! Ich kann dem derzeit nicht die Zeit und Aufmerksamkeit widmen, die es braucht. Ich plane, dies in 2 Wochen ab jetzt anzusprechen.

Irgendwelche Neuigkeiten? Wir brauchen diese Funktion ...

@hatscher viele von uns brauchen es :) Aber schließlich macht es jeder, der an dem Feature (@luto) arbeitet, freiwillig :) Wenn es einen echten kommerziellen Bedarf dafür gibt, würde eine Spende (entweder etwas Geld oder Arbeit) wahrscheinlich helfen, um es zu fahren den Fortschritt weiterleiten. Leider habe ich keine Zeit etwas beizutragen, also bleibt mir nur Hoffnung und Geduld :P

Apropos Beiträge: Wie wäre es, wenn Sie den aktuellen Stand der Entwicklung als PR einreichen, damit andere mitmachen können, wenn sie Lust haben, etwas beizutragen?

Angesichts des traurigen Zustands der GPG-APIs sowohl in Ruby als auch im Allgemeinen könnte die neue GPG-Rust-Implementierung einen Blick wert sein.

Mit einem Körnchen Salz:

BINDUNGEN KOMMEN BALD!

Gibt es Neuigkeiten zur PGP- und S/MIME-Integration? Ich möchte auch einen Betrag spenden, da ich diese Funktion dringend benötige.

Gibt es eigentlich eine Liste mit den geplanten Features der kommenden Versionen?

Hallo @hatscher ,
wir brauchen auch S/MIME und sind mit Zammad über die Kosten im Gespräch. Wollen wir miteinander reden, um uns vielleicht die Kosten für die Integration zu teilen? Vielleicht schickst du mir einfach eine E-Mail (Vorname bei Nachname de).

E-Mail ist unterwegs ;-)

Wir suchen derzeit nach weiteren Personen, die bereit sind, dieses Feature (vielleicht auch zusammen mit der S/MIME-Verschlüsselung als Paket) zu finanzieren. Bitte kontaktieren Sie mich bei Interesse an meinem Vornamen unter Nachname .de. Ich werde nachsehen, wie viele bereitwillige Leute da sind, damit wir uns die Kosten einfach teilen können.

@martinseen Schön zu hören, dass Sie versucht haben, die Finanzierung für dieses Feature zu sichern. Können Sie die erzielten Fortschritte oder die Probleme, auf die Sie gestoßen sind, mitteilen? Der PGP-Support ist derzeit dabei, eine Entscheidung bezüglich eines Wechsels zu Zammad zu treffen, daher wäre jeder Einblick willkommen.

Tut uns leid, aber im Moment können wir keine Informationen zu diesem Thema teilen.
Wir werden diese Ausgabe entsprechend aktualisieren, sobald sich etwas für den Zammad-Core bewegt.

Wenn ich mir Ihre Reaktionszeit von mehreren Monaten und die vorherigen Diskussionen zu diesem Thema anschaue, komme ich zu dem Schluss, dass das Hinzufügen von PGP-Unterstützung zu Zammad für Sie keine Priorität hat oder überhaupt nicht stattfinden wird. (Ich fasse es hier nur für alle zusammen, die in Zukunft kommen und nicht die gesamte Diskussion lesen möchten.)

Hey @rixx - du hast recht. Aktuell arbeiten wir an Aufgaben nach unserem Prioritätenschema:

1.: Support / kundenspezifische Entwicklung
Dies sind die Personen, die Zammad und die von uns veröffentlichten Funktionen finanzieren. Ohne sie wäre Zammad heute nicht hier. Sie zu haben, bedeutet uns wirklich viel und bestärkt uns darin, dass wir auf dem richtigen Weg sind.

2.: 80 % Funktionen / Probleme
Die Freizeit, die wir durch die Betreuung unserer Kunden gewinnen, widmen wir zu 100% dem Produkt. Es ist uns wichtig, gegenüber allen Benutzern unserer Benutzerbasis gleichermaßen fair zu sein. Sobald es jedoch um die Details geht, müssen wir immer mehr Entscheidungen zugunsten einer Partei gegenüber der anderen treffen. Daher arbeiten wir nur an Funktionen und Problemen, die 80 % unserer Nutzerbasis betreffen. Auf diese Weise können wir sicherstellen, dass die Mehrheit unserer Benutzerbasis von den von uns eingeführten Änderungen profitiert.

3.: Persönliches Interesse
Hier bei Zammad steht es jedem frei, Zeit mit Aufgaben zu verbringen, die von persönlichem Interesse sind. Wenn Sie sich ein zweites Mal umsehen, werden Sie feststellen, dass wir auf Probleme und Fragen reagieren, die nicht in die Kategorie der finanzierten oder relevantesten Änderungen fallen. Das liegt daran, dass wir uns wirklich darum kümmern und es genießen, Menschen zu helfen. Allerdings handelt es sich dabei meist um kleinere Aufgaben, da die freie Zeit derzeit sehr begrenzt ist – leider.

Nun zurück zum Thema: PGP fällt derzeit in keine der oben aufgeführten Kategorien. Deshalb haben Sie Recht, wenn Sie sagen, dass es für uns derzeit keine hohe Priorität hat. Sie liegen jedoch falsch, wenn Sie sagen, dass PGP überhaupt nicht stattfinden wird. PGP hat für uns eine vergleichsweise hohe Priorität, es steht sogar auf unserem internen Entwurf für die öffentliche Roadmap, der nur die relevantesten Änderungen enthält.
Die Zeit für PGP ist also noch nicht gekommen, wird aber sicherlich kommen. Je nach Prioritätsschema - früher oder später.
Was mir in Ihrer Zusammenfassung fehlt, ist die Tatsache, dass die PGP-Entwicklung tatsächlich bereits als Gemeinschaftsleistung von @luto mit unserer Unterstützung gestartet wurde (nochmals vielen Dank @luto !). Leider hat sich die Priorität verschoben und die Änderung ist derzeit veraltet. Aber jeder, der das Wissen und die Fähigkeit hat, Dinge aufzugreifen und weiter daran zu arbeiten, wird von uns auf jeden Fall unterstützt!

Neuigkeiten gibt es auch für alle, die sich für das Gesamtthema verschlüsselte Kommunikation interessieren: Die tollen Leute um @martinseener bei barzahlen.de förderten die Entwicklung der S/MIME-Kommunikation (#1961) - die demnächst gestartet wird.

Wenn Sie daran interessiert sind, diese Diskussion zu vertiefen oder sogar einen Beitrag zu leisten, können Sie gerne einen Thread eröffnen oder mir eine PN an das Community-Board senden und dieses Thema beim Thema halten.

Irgendwelche Neuigkeiten zum Thema "S/MIME-Kommunikation" ?

Wenn Sie fragen müssen, verwenden Sie bitte zumindest die richtige Stelle: https://github.com/zammad/zammad/issues/1961

Entschuldigung, wegen fehlendem Feedback in den letzten Monaten beschränke ich diese Ausgabe nur auf Mitwirkende.
Dies soll Lärm reduzieren und uns helfen, uns auf die Probleme zu konzentrieren.

Wenn wir diesbezüglich Neuigkeiten haben, werden wir dieses Problem entsprechend aktualisieren.

Wie Sie vielleicht bei #1961 gesehen haben, haben wir S/MIME-Unterstützung hinzugefügt und werden sie mit der kommenden Version 3.4 von Zammad veröffentlichen 🎉 Vielen Dank an @martinseener drüben bei barzahlen.de für das Sponsoring und damit für die Ermöglichung 🙌
Leider haben wir immer noch nicht die erforderlichen Ressourcen, um auch PGP-Unterstützung hinzuzufügen. Wir haben darüber nachgedacht, einige Dinge auszuprobieren, hatten aber noch keine Gelegenheit dazu. Deshalb wollte ich euch hier ein kurzes Update geben.
Die S/MIME-Integration bietet jedoch ein nahezu vollständiges "Framework" für die Handhabung von sicherem Mailing und eine schöne Referenzimplementierung darüber, wie Dinge integriert/erstellt werden müssen. Es gibt immer noch die großartige Anfangsarbeit von @luto drüben an der Uberspace- Gabel. Wenn jemand bereit ist, ein Risiko einzugehen, helfen wir gerne mit allem, was wir können. Eröffne einfach einen Thread im Community Board und erwähne mich.

Wir halten euch auf dem Laufenden, sobald es neue Informationen gibt - versprochen ✌️