Zammad: PGP

+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 في Zammad :)

تشفير البريد الإلكتروني في الوقت الحاضر أمر لا بد منه. تتطلب اللائحة العامة لحماية البيانات (GDPR) الخصوصية حسب التصميم وبشكل افتراضي ووفقًا لأحدث ما توصلت إليه التقنية.

من الناحية الفنية ، قد يكون من السهل حل هذا من خلال دمج محرك p≡p (خصوصية سهلة للغاية).

+1
كثيرا ما نتلقى رسائل بريدية مشفرة. يعد تصدير التذاكر المشفرة وفك تشفيرها يدويًا أمرًا مؤلمًا ، ومن ثم لا يمكننا حتى الرد على التذاكر عبر نظام التذاكر.

+1
بدون PGP / GPG لا أستطيع الهجرة من OTRS إلى Zammad. لدي العديد من التذاكر المشفرة باستخدام gnupg في OTRS القديم.

+1

نود أن يوقع GnuPG على جميع رسائل البريد الإلكتروني الصادرة عن التذاكر بعد حالة قبيحة للغاية من تزوير بريدنا الإلكتروني لسرقة عملائنا.

ربما يمكن دمج PeP لأنه حل سهل وقابل للاستخدام لتشفير PGP.

أعتقد أيضًا أنها ستكون ميزة رائعة لإرسال رسائل البريد الإلكتروني الموقعة. هذا من شأنه أن يعطي درجة معينة من الثقة للمتلقي ، وأن العنوان حقيقي ويمكن الوثوق به.

ستكون الخطوة التالية هي تشفير الرسالة بالكامل.

martinimonotek نحن نفكر في معالجة جزء GPG من هذا أنفسنا ، في المنزل. هل هناك أي قيود على هذا الدمج ، إذا فعلنا ذلك؟ أي وظيفة تريد رؤيتها أو تتطلبها؟

مرحبًا @ luto - يبدو جيدًا! الأشياء المطلوبة للدمج هي:

• الاختبارات ، ويفضل RSpec
• توثيق
• وثائق Code API
• كود QAd عبر تكوين rubocop و coffeelint

لقد نظرنا بالفعل في بعض جواهر روبي التي توفر واجهة برمجة تطبيقات لثنائي gpg CLI. بقدر ما أتذكر ، لم يكن أي منهم واعدًا حقًا. يرجى التأكد من الاعتماد فقط على التبعيات التي تمت صيانتها / الجودة لأن هذه نقطة حرجة.
التنفيذ المخصص ممكن ولكن ضع في اعتبارك القابلية للتوسعة والصيانة. لا تضع كل المنطق في الوحدة النمطية ولكن قم بإنشاء فئة lib لها. احترام مبدأ المسؤولية الفردية.

يجب أن تتضمن الوظائف جميع أشكال التوقيع والتحقق و en- / فك تشفير إرسال واستلام رسائل البريد 🤓
يجب أن يتم التعامل مع الرسائل الواردة في أقرب وقت ممكن حتى يمكن الوصول إلى المحتوى في المكونات الأخرى.
يجب أن يتم التعامل مع الرسائل الصادرة في وقت متأخر قدر الإمكان حتى تتمكن من الوصول إلى المحتوى الموجود في المكونات الأخرى.

يجب أن تكون هناك واجهة مشرف لطيفة لإدارة المفاتيح العامة والخاصة.

لا تتردد في الاتصال بنا على [email protected] لطرح أي أسئلة لديك والحصول على دعمنا في هذا الشأن. نحن اكثر من سعداء لاستقبال لكم 💪 لنفعلها على طريقة زمماد

لقد حصلنا أيضًا على العميل الأول الذي يتطلب مثل هذا الاتصال ، لذلك أنا أيضًا أصوت لهذا العميل. هل يوجد بالفعل أي تقدم؟ أود أيضًا المساعدة في اختبار إصدار تجريبي.

martinseener afaik هذا ليس على خارطة طريق فريق زمماد. نحن نخطط حاليًا لتنفيذ هذا بمفردنا. إذا كنت ترغب في الانتقال إلى ، حتى نتمكن من إنجازه بشكل أسرع ويمكنك خدمة عميلك ، فلا تتردد في التواصل عبر عنوان البريد الإلكتروني في ملفي الشخصي على github.

thorsteneckel أقوم حاليًا بعمل نموذج أولي لتطبيق لتلقي رسائل البريد في جزأين:

1. فك تشفير البريد في Postmaster::PreFilter : تعيين الرسالة المشفرة كمحتوى ؛ التخلص من الأصل تخزين مفتاح فك التشفير المستخدم في البيانات الوصفية
2. في Postmaster::PostFilter أنشئ كائن GpgCryptoInfo ، قم بإرفاقه بـ Article ؛ تخزين المعلومات مثل مفتاح فك التشفير وحالة التوقيع بشكل دائم

بعض الأسئلة:

• هل تعتقد أن هذا يجب أن يتم تنفيذه باستخدام تلك المرشحات APIs؟ أم يجب أن يكون هذا ثابتًا في 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 على قنوات أخرى غير البريد الإلكتروني فقط. سيضمن وضع ذلك في الاعتبار أن الواجهة الخلفية وواجهة برمجة التطبيقات التي نصممها ستكون سهلة الاختبار والدمج. بعد اقتراحي (مفتوح للمناقشة):

يجب أن يكون هناك فئة تسمى PgpMessage موجودة في الملف lib/pgp_message.rb . تأخذ هذه الفئة وسيطة واحدة مطلوبة والتي ستكون (ربما) سلسلة الرسائل المشفرة / محتوى البريد. مثال:

instance = PgpMessage.new(email_content)

يجب أن يوفر المثيل الواجهة التالية:

• #وقعت؟
• #verified؟ (signature) # التوقيع اختياري ويمكن أن يكون توقيعًا خارجيًا من مرفق على سبيل المثال
• #signature_error
• #مشفر؟
• #decrytable؟
• # مفككه
• #مفتاح
• #خطأ فك التشفير
• #encrypt ( public_key (s) )
• #لافتة

واجهة 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 (في حالة الوجود)
• encrypted_message <- mail ['body']
• signature_status <- تم التحقق منه؟
• التوقيع_الخطأ <- signature_error (في حالة الوجود)

دعم الاختلافات في الرسائل القابلة للفك

يجب أن تكون فئة PgpMessage قادرة على التعامل (على الأقل؟) المجموعات والاختلافات التالية لرسائل PGP الواردة:

• مشفر
• وقعت
• مشفر + موقع
• في النسق
• حاجز

هل لديك ما يكفي من أمثلة البريد الإلكتروني بالفعل؟

يجب أن يكون لدينا قائمة شاملة بحالات الاختبار لتغطية الحالات المختلفة التي يمكن تمديدها بسهولة في المستقبل.

إرسال رسائل مشفرة

نظرًا لأن Zammad يدعم فقط إرسال رسائل بريد إلكتروني بتنسيق HTML ، فنحن بحاجة فقط إلى تغطية إرسال رسائل بريد PGP detached .

المكان الذي ينشئ فيه Zammad بريدًا إلكترونيًا من سمات معينة هو app/models/channel/email_build.rb في طريقة self.build . يجب أن يمتد هذا إلى استخدام فئة PgpMessage لإنشاء مثيل بالسمة المعطاة body واستخدام الطرق encrypted و signed لإنشاء PGP المشفر ومحتوى الجسم الموقع والمرفقات.
للقيام بذلك ، يلزم البحث عن المفاتيح العامة لعناوين البريد الإلكتروني للمستلمين. كيف يمكن للمستخدمين تخزين مفاتيحهم (في ملفهم الشخصي) ليست واضحة حتى الآن. سأناقش هذا داخليًا وأعلمك بذلك.

أعتقد أنه لا ينبغي أن يكون هناك خيار لإرسال رسائل بريد غير مشفرة بمجرد تكوين PGP ودعم المستلم لها. نحن بحاجة لتوضيح هذا ولكن حتى ذلك الحين يجب أن يكون هذا هو السبيل للذهاب.

واجهة المسؤول

يجب عزل هذا عن الوظيفة الأساسية وسيتم وصفه لاحقًا. أعتقد أنك ستحتاج إلى دعمنا في هذا الشأن. سأناقشها داخليًا وأعلمك كيف نتعامل معها.

استنتاج

يجب أن يكون هذا كافياً الآن ويشير في الاتجاه الصحيح. من المحتمل أن نصل إلى بعض النقاط التي يتعين علينا فيها إعادة تنظيم الحالات الأخرى وتغطيتها ، ولكن دعنا نظهرها أولاً.
لا تتردد في طرح أي أسئلة إذا ظهرت.

إنني أتطلع إلى رؤية ومراجعة التغييرات الخاصة بك 🤓

شكرا لدعمكم 🚀
ثورستن

لأكون صريحًا ، لم أجد أي جوهرة أحب أن يكون لها تبعية. تبدو جميعها غير صيانة أو معقدة أو تحتاج إلى تجميع C من التمديدات. قد يكون من المفيد المحاولة إذا لم نتمكن من الوصول إلى PGP CLI فقط. ما رأيك؟

PGP CLI غير مستقر ويجب ، وفقًا لـ GPG ، عدم استخدامه كواجهة برمجة تطبيقات. لقد نجحت في استخدام ruby-gpgme حتى الآن ، لذلك هذا هو المسار الذي أود اتباعه في الوقت الحالي. بالنظر إلى أنه بقدر ما أعرف أن GPG ليس لديها واجهة برمجة تطبيقات ، ولكن فقط مكتبات من المستوى C ، لا أعتقد أننا سنهرب بدون أي امتدادات C .. باستثناء إعادة تنفيذ GPG في روبي ربما ، ولكن لا أعرف أي شيء.

شكرا لتوضيحها لم أكن على علم بذلك. يبدو جيدا بالنسبة لي بعد ذلك. إنه أمر مقلق بعض الشيء أن بنياتهم تفشل ولكن سألقي نظرة عليها.

مرحبا! كما تمت مناقشته سابقًا ، بدأت هذه المشكلة كطلب لوظيفة 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 ، لذا يبدو السجل أجمل ؛ تم تحديد جميع الجرائم الأخرى باليد. الشرطي سعيد في الغالب الآن :)

قد تلاحظ وجود بيثونية في الكود. بينما أحاول محاكاة طريقة الياقوت في القيام بالأشياء بأفضل ما يمكنني ، ما زلت رجل ثعبان من خلال التجارة ؛) من فضلك فقط أشر إلى الأشياء ، إذا بدت معك في الاتجاه المعاكس. اشتعلت Rubocop عددًا قليلاً منهم: sweat_smile:

لطيف! لقد لاحظت للتو أن هناك نوعًا واحدًا على الأقل من التغييرات التي تم تطبيقها لا تتطابق مع تكوين rubocop الخاص بنا: استخدام unless بدلاً من if s. لذلك يبدو أن روبوكوب الخاص بك يقوم بالكثير هنا.

أوه ، الثعبان جيد بالنسبة لي. لا شيء للشكوى منه حتى الآن 🤓

مرحبًا luto - أردت فقط إلقاء نظرة على الوضع الحالي للتطوير ولكن لاحظت أنه لم يكن هناك أي التزام منذ 24 يومًا. هل هناك أي شيء أستطيع القيام به؟

هل هناك أي شيء أستطيع القيام به؟

إصلاح مشاريعنا الداخلية الأخرى: wink:: grin:
ليس هناك مانع في حدود زماد ، مجرد ضيق عام للوقت. يجب أن يستمر العمل على هذا الأسبوع المقبل.

thorsteneckel لقد أصابتني نوعًا ما بعقبة. لا يميز Gpg (أو gpgme على الأقل) بين "البريد الإلكتروني مشفر ، لكن لا يمكن فك تشفيره" و "البريد الإلكتروني مشفر وكل شيء على ما يرام" في معظم الحالات. هذا السلوك غير متوافق مع الأساليب encrypted? و decryptable? الموضحة سابقًا. في الوقت الحالي ، لدي عدد من الاختراقات لاكتشاف رسائل البريد المشفرة ، ولكن ليست قابلة للفك ، لكن لا يمكنني تشغيلها في جميع الحالات.

ما رأيك في عدم التمييز بين فك التشفير والتشفير في واجهة المستخدم؟ باستثناء الحالات الواضحة مثل عدم وجود عنوان رسالة GPG ، ofc.

متى نتوقع التنفيذ والتكامل في زمماد؟ هل التنفيذ مخطط لإصدار معين؟

أي أخبار؟

لدي شعور بأن أولئك الذين يمكنهم تقديم تطوير هذا المكون الإضافي لديهم أشياء أخرى في أذهانهم ولكنهم يتحققون من الردود المتعلقة بهذه المشكلة.
إذا كنت ترغب في لفت انتباههم إلى هذا ، فيمكنك إرسال بريد إلكتروني إليهم: [email protected] - لقد فعلت ذلك بالفعل - أو أرسل لهم تغريدة وديةubernauten

hatscher آسف على التأخير ؛ كما خمّن @ 0xErnie ، لدي حاليًا أشياء أخرى يجب القيام بها ، لكن هذه الميزة لا تزال على رادارنا. يرجى ملاحظة أنني أعمل حاليًا على هذا منفردًا ، وليس كجزء من فريق شركة Zammad، Inc. وبدون أي مؤسس خارجي. لذلك قد يستغرق هذا بعض الوقت.

بالنسبة إلى أدوات الحظر ، هناك سؤال واحد مفتوح هنا لـ thorsteneckel ، بالإضافة إلى سؤال خاص حول كيفية معالجة محتوى واجهة المستخدم الخاص بهذا الأمر. لا تتردد في الاتصال به ، إذا كنت ترغب في المشاركة للمضي قدمًا ،hatscher! لكن العائق الرئيسي هو ضيق الوقت لدي.

آسف على الرد المتأخر ، وخاصة بالنسبة لك @ luto ! لا يمكنني إعطاء هذا الوقت والاهتمام الذي يحتاجه حاليًا. أخطط لمعالجة هذا في غضون أسبوعين من الآن.

أي أخبار؟ نحتاج هذه الميزة ...

hatscher يحتاجها الكثير منا :) ولكن بعد كل شيء ، كل شخص يعمل على الميزة (@ luto) يقوم بذلك طواعية :) إذا كانت هناك حاجة تجارية حقيقية لها ، أعتقد أن التبرع (سواء بعض العجين أو العمل) سيساعد في القيادة إلى الأمام التقدم. لسوء الحظ ليس لدي الوقت للمساهمة ، لذلك كل ما تبقى لي هو الأمل والصبر: P

التحدث عن المساهمات: ماذا عن تقديم الوضع الحالي للتطور كعلاقات عامة حتى يتمكن الآخرون من الانضمام إذا شعروا أنهم قادرون على المساهمة؟

نظرًا للحالة المؤسفة لـ GPG-APIs في كل من الياقوت وبشكل عام ، قد يكون تنفيذ صدأ GPG الجديد يستحق نظرة.

مع ذرة من الملح:

ارتباطات قريبا!

هل هناك أي أخبار بخصوص تكامل PGP و S / MIME؟ أود أيضًا التبرع بمبلغ لأنني بحاجة ماسة إلى هذه الميزة.

هل توجد بالفعل قائمة بالميزات المخطط لها للإصدارات القادمة؟

مرحبًا hatscher ،
نحتاج أيضًا إلى S / MIME ونجري محادثات مع Zammad حول التكاليف. هل نريد التحدث مع بعضنا البعض حتى نتمكن من مشاركة تكاليف الاندماج؟ ربما فقط أرسل لي بريدًا إلكترونيًا (الاسم الأول في lastname de).

البريد الإلكتروني في طريقه إليك ؛-)

نحن نبحث حاليًا عن أشخاص آخرين يرغبون في تمويل هذه الميزة (ربما أيضًا مع تشفير S / MIME كحزمة). الرجاء الاتصال بي إذا كنت مهتمًا باسمي الأول على lastname .de. سوف أتحقق وأرى عدد الأشخاص المستعدين هناك حتى نتمكن من مشاركة التكاليف.

martinseener من الرائع معرفة أنك حاولت تأمين التمويل لهذه الميزة. هل يمكنك مشاركة التقدم الذي تم إحرازه أو المشكلات التي واجهتك؟ يقوم دعم PGP حاليًا باتخاذ قرار بشأن الانتقال إلى زماد أو كسره ، لذا فإن أي فكرة ستكون موضع تقدير.

معذرة ، لكن في الوقت الحالي لا يمكننا مشاركة أي معلومات حول هذا الموضوع.
سنقوم بتحديث هذه المشكلة وفقًا لذلك بمجرد أن يتحرك شيء ما لـ Zammad-Core.

بالنظر إلى وقت استجابتك لعدة أشهر والمناقشات السابقة حول هذه المسألة ، أخلص إلى أن إضافة دعم PGP إلى Zammad ليس أولوية بالنسبة لك أو لن يحدث على الإطلاق. (فقط قم بتلخيصها هنا لأي شخص يأتي في المستقبل ولا يريد قراءة المناقشة بأكملها.)

يا rixx - أنت على حق. نحن نعمل حاليًا على المهام بناءً على مخطط الأولوية لدينا:

الأول: دعم / تطوير مخصص
هؤلاء هم الأشخاص الذين يمولون زمماد والميزات التي نطلقها. لم يكن زمّاد ليكون هنا اليوم بدونهم. وجودهم يعني حقًا الكثير بالنسبة لنا ويشجعنا على السير على الطريق الصحيح.

الثاني: 80٪ ميزات / مشاكل
وقت الفراغ الذي نكسبه من دعم عملائنا هو قضاء 100٪ في المنتج. من المهم بالنسبة لنا أن نكون منصفين على قدم المساواة مع أي مستخدم لقاعدة مستخدمينا. ومع ذلك ، بمجرد أن يتعلق الأمر بالتفاصيل ، هناك المزيد والمزيد من القرارات التي نحتاج إلى اتخاذها لصالح طرف على الآخر. لذلك نحن نعمل فقط على الميزات والقضايا التي تؤثر على 80٪ من قاعدة مستخدمينا. بهذه الطريقة يمكننا ضمان أن غالبية قاعدة مستخدمينا تستفيد من التغييرات التي نقدمها.

ثالثا: المصلحة الشخصية
هنا في 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 . إذا كان أي شخص على استعداد لاغتنام الفرصة ، يسعدنا تقديم المساعدة بكل ما في وسعنا. فقط افتح موضوعًا في لوحة المجتمع واذكرني.

نبقيك على اطلاع كلما توفرت معلومات جديدة - وعدت ✌️