Zammad: पीजीपी

एस/एमआईएमई समर्थन के लिए +1

ठीक है, मैंने शीर्षक बदल दिया है। बेशक सबसे अच्छा होगा अगर यह दोनों चीजों की पेशकश करेगा।

X.509 एन्क्रिप्टेड मेल भेजने और प्राप्त करने की संभावना के लिए मैं सराहना करता हूं।

हाँ, X.509 हस्ताक्षरित या एन्क्रिप्टेड मेल भेजने और प्राप्त करने में सक्षम होना बहुत अच्छा होगा।

तो X.509 एन्क्रिप्टेड मेल S/MIME मेल हैं। मैं व्यक्तिगत रूप से पीजीपी को अधिक पसंद करूंगा (क्योंकि यह अधिक व्यापक है), लेकिन यह मुद्दा दोनों प्रणालियों के बारे में है। मैं

मैं विशलिस्ट में एन्क्रिप्टेड सूचनाएं जोड़ूंगा - इसलिए उपयोगकर्ताओं को अपनी प्रोफ़ाइल में सार्वजनिक कुंजी जोड़ने में सक्षम होना चाहिए।

एफवाईआई: रेडमाइन के लिए ऐसी कार्यक्षमता वाला एक अच्छा प्लगइन मौजूद है: https://github.com/C3S/redmine_openpgp

ऐसा लगता है कि यह मणि वास्तव में बनाए नहीं रखा गया है (अंतिम प्रतिबद्ध), लेकिन कई अन्य हैं । व्यक्तिगत रूप से मैं कहूंगा कि इस मणि की सबसे हालिया प्रतिबद्धता है।

आज हमारे पास पहला ग्राहक अनुरोध था जिसमें पीजीपी-सहायता मांगी गई थी क्योंकि वह एक अनएन्क्रिप्टेड कनेक्शन के माध्यम से अपने बैंक विवरण का अनुरोध नहीं करना चाहती थी। इसलिए +1

+1।
हम आईटी एसईसी समुदाय के साथ काम कर रहे हैं और पीजीपी एन्क्रिप्टेड मेल के टन प्राप्त करते हैं जिन्हें हम ज़माद में नहीं खोल सकते हैं, इसलिए हमें निर्यात और डिक्रिप्ट करना होगा, यह एक वर्कफ़्लो का नरक है। ज़मद में पीजीपी और शायद एस/एमआईएमई मेल का समर्थन करने के लिए +1 :)

आजकल ई-मेल एन्क्रिप्शन एक जरूरी है। सामान्य डेटा संरक्षण विनियमन (जीडीपीआर) के लिए डिज़ाइन द्वारा और डिफ़ॉल्ट रूप से और अत्याधुनिक स्थिति के अनुसार गोपनीयता की आवश्यकता होती है।

तकनीकी रूप से इसे p≡p इंजन (काफी आसान गोपनीयता) को एकीकृत करके हल करना आसान हो सकता है।

+1
हम अक्सर एन्क्रिप्टेड मेल प्राप्त करते हैं। एन्क्रिप्टेड टिकटों को निर्यात और मैन्युअल रूप से डिक्रिप्ट करना दर्दनाक है, और फिर हम टिकट सिस्टम के माध्यम से टिकटों का जवाब भी नहीं दे सकते।

+1
पीजीपी/जीपीजी के बिना मैं ओ.टी.आर.एस. से ज़माद में प्रवास नहीं कर सकता। मेरे पुराने OTRS में gnupg के साथ कई एन्क्रिप्टेड टिकट हैं।

+1

हमारे ग्राहकों को लूटने के लिए हमारे ईमेल को नकली बनाने के एक बहुत ही बदसूरत मामले के बाद हम सभी आउटगोइंग टिकट ईमेल पर जीएनयूपीजी पर हस्ताक्षर करना चाहते हैं।

शायद पीईपी को एकीकृत किया जा सकता है क्योंकि यह पीजीपी एन्क्रिप्शन के लिए एक आसान और उपयोगी समाधान है।

मुझे यह भी लगता है कि हस्ताक्षरित ईमेल भेजने के लिए यह एक शानदार सुविधा होगी। यह प्राप्तकर्ता के लिए कुछ हद तक आत्मविश्वास देगा, कि पता वास्तविक है और उस पर भरोसा किया जा सकता है।

अगला कदम संदेश को पूरी तरह से एन्क्रिप्ट करना होगा।

@martini @monotek हम स्वयं इसके GPG भाग से निपटने के बारे में सोच रहे हैं, इन-हाउस। यदि हम ऐसा करते हैं तो क्या इसे विलय करने पर कोई प्रतिबंध है? कोई कार्यक्षमता जिसे आप देखना चाहते हैं या जिसकी आवश्यकता है?

हाय @luto - अच्छा लगता है! विलय के लिए आवश्यक चीजें हैं:

• टेस्ट, अधिमानतः आरएसपीईसी
• प्रलेखन
• कोड एपीआई प्रलेखन
• हमारे रूबोकॉप और कॉफ़ीलिंट कॉन्फ़िगरेशन के माध्यम से QAd कोड

हमने पहले से ही कुछ रूबी रत्नों को देखा है जो जीपीजी सीएलआई बाइनरी को एपीआई प्रदान करते हैं। जहां तक ​​मुझे याद है उनमें से कोई भी वास्तव में आशाजनक नहीं लग रहा था। कृपया सुनिश्चित करें कि केवल अनुरक्षित/गुणवत्ता निर्भरता पर ही भरोसा करें क्योंकि यह एक महत्वपूर्ण बिंदु है।
एक कस्टम कार्यान्वयन संभव है लेकिन एक्स्टेंसिबिलिटी और रखरखाव को ध्यान में रखें। मॉड्यूल में सभी तर्क न डालें बल्कि इसके लिए एक lib वर्ग बनाएं। एकल जिम्मेदारी सिद्धांत का सम्मान करें।

कार्यक्षमता में मेल भेजने और प्राप्त करने के हस्ताक्षर, सत्यापन और एन-/डिक्रिप्शन के सभी बदलाव शामिल होने चाहिए
आने वाले संदेशों को संभालना जल्द से जल्द किया जाना चाहिए ताकि सामग्री अन्य घटकों में पहुंच योग्य हो।
अन्य घटकों में सामग्री तक पहुँचने में सक्षम होने के लिए आउटगोइंग संदेशों को संभालना यथासंभव देर से किया जाना चाहिए।

सार्वजनिक और निजी कुंजियों को प्रबंधित करने के लिए एक अच्छा व्यवस्थापक इंटरफ़ेस होना चाहिए।

अपने कोई भी प्रश्न पूछने और इस पर हमारा समर्थन प्राप्त करने के लिए बेझिझक हमसे [email protected] पर संपर्क करें। हम आपका स्वागत पाकर बहुत खुश हैं आइए इसे जम्मद तरीके से करें

हमें पहला ग्राहक भी मिला जिसे इस तरह के संचार की आवश्यकता है, इसलिए मैं भी इसे वोट देता हूं। क्या पहले से ही कोई प्रगति हुई है? मैं बीटा के परीक्षण में भी मदद करना चाहता/चाहती हूं।

@martinseener afaik यह ज़माद टीम के रोडमैप पर नहीं है। वर्तमान में हम इसे अपने आप लागू करने की योजना बना रहे हैं। यदि आप चिप करना चाहते हैं, तो हम इसे तेजी से कर सकते हैं और आप अपने ग्राहक की सेवा कर सकते हैं, मेरे जीथब प्रोफाइल पर ईमेल-पते के माध्यम से बेझिझक पहुंचें।

@thorsteneckel मैं वर्तमान में दो भागों में मेल प्राप्त करने के लिए एक कार्यान्वयन प्रोटोटाइप कर रहा हूँ:

1. मेल को Postmaster::PreFilter में डिक्रिप्ट करें : डिक्रिप्टेड संदेश को सामग्री के रूप में सेट करें; मूल फेंक दो; मेटाडेटा में उपयोग की गई डिक्रिप्ट-कुंजी को स्टोर करें
2. Postmaster::PostFilter में एक GpgCryptoInfo ऑब्जेक्ट बनाएं, इसे Article के साथ अटैच करें; उपयोग की गई डिक्रिप्ट-कुंजी और हस्ताक्षर स्थिति जैसी जानकारी को स्थायी रूप से संग्रहीत करें

कुछ प्रश्न:

• क्या आपको लगता है कि इसे उन फ़िल्टर एपीआई का उपयोग करके लागू किया जाना चाहिए? या इसे Channel::EmailParser में हार्डकोड किया जाना चाहिए?
• क्या कोई Postmaster::PreFilter ग्राहक हैं, जिन्हें डिक्रिप्टेड संदेश सामग्री तक पहुंच की आवश्यकता है? इस मामले में एक हार्डकोडेड कार्यान्वयन या Postmaster::EarlyPreFilter की आवश्यकता है।
• एन्क्रिप्ट/डिक्रिप्ट/हस्ताक्षर/सत्यापित करने के लिए उपयोग की गई कुंजी के साथ-साथ प्राप्त मेल की हस्ताक्षर स्थिति को छोड़कर कोई जानकारी है जिसे आप स्थायी रूप से रखना चाहते हैं?

साथ ही, एक सामान्य प्रश्न: EmailParser या फ़िल्टर _decrypt_ मेल के लिए उपयुक्त स्थान प्रतीत होते हैं; क्या आप उन्हें एन्क्रिप्ट करने के लिए एक "सही" जगह के बारे में सोच सकते हैं?

मुझे आशा है कि यह मुद्दा कार्यान्वयन प्रश्न पूछने के लिए सही जगह है। यदि नहीं, तो कृपया मुझे दूसरे की ओर इंगित करें, अधिमानतः सार्वजनिक, एक :) धन्यवाद!

हाय @luto - मैं वर्तमान में इसके बारे में अपने विचार लिख रहा हूं। चूंकि यह एक बड़ा और महत्वपूर्ण विषय है इसलिए इसमें कुछ समय लगता है। मैं इसे सप्ताह के अंत तक पूरा करने की कोशिश करता हूं। समझने के लिए धन्यवाद।

छोटा अद्यतन: Postmaster::PreFilter फ़िल्टर का आदेश दिया गया है। मैंने वर्तमान में IdentifySender के ठीक बाद अपना स्थान रखा है, इसलिए मैं यह पता लगा सकता हूं कि कौन सी gpg कुंजियों को आज़माना है। यह जानते हुए, फ़िल्टर मेरे लिए डिक्रिप्ट करने के लिए सही जगह प्रतीत होते हैं।

@thorsteneckel समय निकालने के लिए धन्यवाद! आपके लेखन का इंतज़ार रहेगा. :)

हाय @luto , यह सुनकर खुशी हुई! जैसा कि आपने प्रस्ताव दिया था, मुझे इस मुद्दे में समन्वय करना अच्छा लगता है। इसलिए यह पारदर्शी होगा और हम तकनीकी दस्तावेज के लिए साझा की गई जानकारी का पुन: उपयोग कर सकते हैं। आप इस मुद्दे को अपने कांटे की अपनी कार्य शाखा में संदर्भित कर सकते हैं और इसे यहां संदर्भित किया जाएगा। परिवर्तन पूर्ण होने के बाद कृपया एक पुल अनुरोध बनाएं। इस बीच, मैं आपकी शाखा की जाँच करूँगा और परिवर्तन देखूँगा।
हमें S/MIME कार्यक्षमता को एक अलग मुद्दे पर ले जाना चाहिए क्योंकि हम इसे अभी लागू नहीं करेंगे।

आपके सवालों के बारे में: आप पूरी तरह से सही रास्ते पर हैं। मैं कुछ बातें लिखूंगा और रास्ते में आपके सवालों का जवाब दूंगा।

सामान्य विकास

हमारे अनुभव में परीक्षण संचालित विकास (आरएसपीसी के साथ) इस तरह के कार्यों के लिए सबसे अच्छा काम करता है। यह आप पर निर्भर करता है कि आप इसे कैसे प्राप्त करते हैं लेकिन हमें निश्चित रूप से कार्यक्षमता के लिए एक व्यापक परीक्षण सूट की आवश्यकता होगी। इसलिए मैं आपको परीक्षण को आसान बनाने के लिए एक आरएसपीईसी सहायक प्रदान करूंगा और जिस तरह से मैं कर सकता हूं उस पर आपका समर्थन करूंगा। मैं इसे अगले दिनों में develop शाखा में जोड़ दूंगा। आपको इस शाखा का उपयोग अपने आधार के रूप में करना चाहिए क्योंकि यह हमारी कार्यशील शाखा भी है। यह मास्टर में विलीन हो जाएगा और भविष्य में स्थिर की जगह लेगा।

पोस्टमास्टर :: प्रीफ़िल्टर

Postmaster::PreFilter s सही जगह है। आप फ़िल्टर पंजीकरण के नाम पर एक संख्या उपसर्ग द्वारा निष्पादन के समय को प्रभावित कर सकते हैं। कम नंबरों को पहले निष्पादित किया जाएगा ।
सिस्टम के लिए पहले से ही एक माइग्रेशन शुरू कर दिया है जो सेटिंग जोड़ता है, भी आवश्यक है ।
मैं एक नाम को app/models/channel/filter/decrypt.rb जैसा कुछ प्रस्तावित करूंगा - लेकिन अंत में यह आप पर निर्भर है।

पंजीकरण हो जाने के बाद ज़म्मद प्रत्येक आने वाली मेल के लिए फ़िल्टर निष्पादित करेगा।

पीजीपी संदेश वर्ग

चूंकि हम इस बिंदु पर केवल पीजीपी लागू करेंगे, इसलिए हमें यह सुनिश्चित करना होगा कि हम बाद में एस/एमआईएमई जोड़ने के लिए बाधाएं नहीं जोड़ेंगे। इसके अतिरिक्त भविष्य में केवल ईमेल के अलावा अन्य चैनलों पर पीजीपी का समर्थन करना आवश्यक हो सकता है। इसे ध्यान में रखने से यह सुनिश्चित होगा कि हमारे द्वारा डिज़ाइन किया गया बैकएंड और एपीआई परीक्षण और एकीकृत करने में आसान होगा। मेरे प्रस्ताव के बाद (चर्चा के लिए खुला):

फ़ाइल में स्थित PgpMessage नामक एक वर्ग होना चाहिए lib/pgp_message.rb । यह वर्ग एक आवश्यक तर्क लेता है जो (संभवतः) एन्क्रिप्टेड संदेश स्ट्रिंग/मेल सामग्री होगी। उदाहरण:

instance = PgpMessage.new(email_content)

उदाहरण को निम्नलिखित इंटरफ़ेस प्रदान करना चाहिए:

• #हस्ताक्षरित?
• #सत्यापित?(हस्ताक्षर) # हस्ताक्षर वैकल्पिक है और एक बाहरी हस्ताक्षर हो सकता है जैसे संलग्नक
• #हस्ताक्षर_त्रुटि
• #क्रिप्टेड?
• #डिक्रीटेबल?
• #डिक्रिप्टेड
• #चाभी
• #डीक्रिप्शन त्रुटि
• #एन्क्रिप्ट ( public_key(s) )
• #संकेत

पीजीपी इंटरफ़ेस

सच कहूं तो मुझे ऐसा कोई रत्न नहीं मिला जिसे मैं निर्भरता के रूप में रखना चाहता हूं। वे सभी अनियंत्रित, जटिल दिखते हैं या एक्सटेंशन के सी संकलन की आवश्यकता होती है। यह कोशिश करने लायक हो सकता है अगर हम सिर्फ पीजीपी सीएलआई तक नहीं पहुंच सकते। तुम क्या सोचते हो?

पोस्टमास्टर में PgpMessage एकीकरण :: डिक्रिप्शन के लिए प्रीफिल्टर

PgpMessage क्लास का उपयोग तब Postmaster::PreFilter में किया जा सकता है ताकि एक इंस्टेंस को इनिशियलाइज़ किया जा सके और प्रासंगिकता के लिए संदेश की जाँच की जा सके। यदि यह एक पीजीपी एन्क्रिप्टेड संदेश है तो हम अपनी जरूरत के डेटा को निकालने के लिए अन्य तरीकों का उपयोग करने के लिए आगे बढ़ सकते हैं और दिए गए mail हैश में body और attachments के लिए सामग्री को अधिलेखित कर सकते हैं।
इसके अतिरिक्त हमें लेख में कुछ मेटा जानकारी (जैसा कि आपने पहले ही बताया है) स्टोर करनी होगी जो x-zammad-article-preferences हेडर सेट करके बनाई जाएगी:

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

मुझे लगता है कि निम्नलिखित मेटाडेटा पर्याप्त होना चाहिए:

• डिक्रिप्शन_की <- कुंजी
• decryption_error <- decryption_error (अस्तित्व के मामले में)
• एन्क्रिप्टेड_मैसेज <- मेल ['बॉडी']
• सिग्नेचर_स्टैटस <- सत्यापित?
• सिग्नेचर_एरर <- सिग्नेचर_एरर (अस्तित्व के मामले में)

डिक्रिप्टेबल संदेशों की समर्थित विविधताएं

PgpMessage वर्ग आने वाले PGP संदेशों के निम्नलिखित संयोजनों और विविधताओं को (कम से कम?) संभालने में सक्षम होना चाहिए:

• कूट रूप दिया गया
• पर हस्ताक्षर किए
• एन्क्रिप्टेड + हस्ताक्षरित
• इन - लाइन
• अनुरक्ति

क्या आपके पास पहले से ही पर्याप्त उदाहरण मेल हैं?

हमारे पास विभिन्न मामलों को कवर करने के लिए परीक्षण मामलों की एक व्यापक सूची होनी चाहिए जिसे भविष्य में आसानी से बढ़ाया जा सकता है।

गुप्त संदेश भेजना

चूंकि Zammad केवल HTML ईमेल भेजने का समर्थन करता है, इसलिए हमें केवल detached PGP मेल भेजने को कवर करने की आवश्यकता है।

वह स्थान जहां ज़माद दी गई विशेषताओं से एक ईमेल बनाता है app/models/channel/email_build.rb में self.build पद्धति में है। इसे दिए गए body विशेषता के साथ एक उदाहरण बनाने के लिए PgpMessage वर्ग का उपयोग करने के लिए बढ़ाया जाना चाहिए और पीजीपी एन्क्रिप्टेड बनाने के लिए encrypted और signed विधियों का उपयोग करना चाहिए और शरीर की सामग्री और अनुलग्नकों पर हस्ताक्षर किए।
ऐसा करने के लिए प्राप्तकर्ता ईमेल पते की सार्वजनिक कुंजी को देखना आवश्यक है। उपयोगकर्ता अपनी कुंजी (अपनी प्रोफ़ाइल में) कैसे संग्रहीत कर सकते हैं यह अभी तक स्पष्ट नहीं है। मैं आंतरिक रूप से इस पर चर्चा करूंगा और आपको बता दूंगा।

मुझे लगता है कि एक बार पीजीपी कॉन्फ़िगर हो जाने के बाद और प्राप्तकर्ता इसका समर्थन करने के बाद अनएन्क्रिप्टेड मेल भेजने का कोई विकल्प नहीं होना चाहिए। हमें इसे स्पष्ट करने की आवश्यकता है लेकिन तब तक यही रास्ता तय करना चाहिए।

व्यवस्थापक इंटरफ़ेस

इसे मुख्य कार्यक्षमता से अलग किया जाना चाहिए और बाद में इसका वर्णन किया जाएगा। मुझे लगता है कि आपको इस पर हमारे समर्थन की आवश्यकता होगी। मैं आंतरिक रूप से इस पर चर्चा करूंगा और आपको बताऊंगा कि हम इस पर कैसे पहुंचते हैं।

निष्कर्ष

यह अब तक पर्याप्त होना चाहिए और सही दिशा में इंगित करना चाहिए। हम शायद कुछ स्थानों पर पहुंचेंगे जहां हमें अन्य मामलों को फिर से संगठित करना होगा और उन्हें कवर करना होगा लेकिन उन्हें पहले उठने दें।
यदि कोई प्रश्न उठता है तो बेझिझक पूछें।

मैं आपके परिवर्तनों को देखने और उनकी समीक्षा करने के लिए उत्सुक हूं

आपके समर्थन के लिए धन्यवाद
Thorsten

सच कहूं तो मुझे ऐसा कोई रत्न नहीं मिला जिसे मैं निर्भरता के रूप में रखना चाहता हूं। वे सभी अनियंत्रित, जटिल दिखते हैं या एक्सटेंशन के सी संकलन की आवश्यकता होती है। यह कोशिश करने लायक हो सकता है अगर हम सिर्फ पीजीपी सीएलआई तक नहीं पहुंच सकते। तुम क्या सोचते हो?

PGP CLI स्थिर नहीं है और GPG के अनुसार इसे API के रूप में उपयोग नहीं किया जाना चाहिए। मुझे अब तक रूबी-जीपीजीएम का उपयोग करने में सफलता मिली है, इसलिए मैं अभी के लिए यही मार्ग अपनाना चाहता हूं। यह देखते हुए कि जहां तक ​​​​मुझे पता है कि जीपीजी में एपीआई नहीं है, लेकिन केवल सी-स्तरीय पुस्तकालय हैं, मुझे नहीं लगता कि हम बिना किसी सी एक्सटेंशन के दूर हो जाएंगे .. रूबी में जीपीजी के पुन: कार्यान्वयन को छोड़कर, लेकिन मुझे किसी का पता नहीं है।

इसे स्पष्ट करने के लिए धन्यवाद। मुझे इसकी जानकारी नहीं थी। तब मुझे अच्छा लगता है। यह थोड़ा चिंताजनक है कि उनके निर्माण विफल हो रहे हैं लेकिन मैं इस पर एक नजर डालूंगा।

सुनो! जैसा कि पहले चर्चा की गई थी, यह मुद्दा पीजीपी कार्यक्षमता के अनुरोध के रूप में शुरू हुआ था। बाद में हमने S/MIME को भी जोड़ा। लेकिन चूंकि दोनों स्वतंत्र रूप से लागू होते हैं और अलग-अलग प्रौद्योगिकियां हैं, इसलिए हमने S/MIME आवश्यकता को नए अंक #1961 में स्थानांतरित करने का निर्णय लिया। यदि आप किसी प्रगति में रुचि रखते हैं तो वहां सदस्यता लेने के लिए स्वतंत्र महसूस करें। इश्यू ट्रैकर पर शोर से बचने के लिए सामुदायिक बोर्ड में चर्चा की जानी चाहिए। धन्यवाद!

इसलिए मैं आपको परीक्षण को आसान बनाने के लिए एक आरएसपीईसी सहायक प्रदान करूंगा और जिस तरह से मैं कर सकता हूं उस पर आपका समर्थन करूंगा। मैं इसे अगले दिनों में विकसित शाखा में जोड़ दूंगा।

@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 वैकल्पिक है और आपके मामले में इसकी आवश्यकता नहीं होनी चाहिए।

धन्यवाद!
FYI करें: शाखा अब हमारे कांटे में रहती है। मेरे जाते ही किसी भी कमिट पर बेझिझक टिप्पणी करें। इसमें शामिल सभी लोगों के लिए अंतिम समीक्षा को आसान और संक्षिप्त रखना चाहिए :)

हाय @luto - आपको इस गति से इस पर काम करते हुए देखकर बहुत अच्छा लगा। मैंने देखा कि कोड ऐसा नहीं लगता है कि इसे रूबोकॉप से ​​चेक किया गया था। हम दोनों तरह की फाइलों के लिए ज़माद स्टाइल गाइड सुनिश्चित करने के लिए रूबोकॉप और कॉफ़ीलिंट का उपयोग करते हैं। यदि आप स्वचालित रूप से जांच करना चाहते हैं तो एक पूर्व-प्रतिबद्ध फ़िल्टर कॉन्फ़िगरेशन भी उपलब्ध है। मुझे बताएं कि क्या मैं आपको इसके बारे में और जानकारी दे सकता हूं।

ओह, पक्की बात। मैंने pre-commit install के साथ-साथ मेरे संपादक के लिए मिलान एक्सटेंशन के साथ हुक स्थापित किया। इंडेंटेशन filter-branch के माध्यम से तय किया गया था, इसलिए इतिहास अच्छा दिखता है; अन्य सभी अपराध हाथ से तय किए गए थे। पुलिस वाला अब ज्यादातर खुश है :)

आप कोड में पाइथोनिस्म्स के साथ देख सकते हैं। जबकि मैं जितना हो सके चीजों को करने के रूबी तरीके का अनुकरण करने की कोशिश करता हूं, मैं अभी भी व्यापार से एक अजगर आदमी हूं;) कृपया चीजों को इंगित करें, अगर वे आपको पीछे की ओर लगते हैं। रूबोकॉप ने उनमें से कुछ को पकड़ा :sweat_smile:

अच्छा! मैंने अभी देखा है कि कम से कम एक प्रकार के परिवर्तन लागू हैं जो हमारे रूबोकॉप कॉन्फ़िगरेशन से मेल नहीं खाते हैं: नकारात्मक if s के बजाय unless का उपयोग करना। तो ऐसा लगता है कि आपका रूबोकॉप यहाँ बहुत कुछ कर रहा है।

ओह पाइथोनिस्म मेरे लिए ठीक है। अब तक शिकायत करने के लिए कुछ भी नहीं

हाय @luto - मैं सिर्फ विकास की वर्तमान स्थिति पर एक नज़र डालना चाहता था लेकिन देखा कि 24 दिनों से कोई प्रतिबद्धता नहीं थी। क्या मै कुछ कर सकता हुं?

क्या मै कुछ कर सकता हुं?

हमारी अन्य आंतरिक परियोजनाओं को ठीक करना :wink: :grin:
ज़माद की सीमा के भीतर कोई अवरोधक नहीं है, बस समय की एक सामान्य कमी है। इस पर अगले हफ्ते काम जारी रहना चाहिए।

@thorsteneckel मैं एक तरह का रोड़ा मारता हूं। Gpg (या कम से कम gpgme) ज्यादातर मामलों में "ईमेल एन्क्रिप्टेड है, लेकिन डिक्रिप्ट नहीं कर सकता" और "ईमेल एन्क्रिप्टेड है और सब ठीक है" के बीच अंतर नहीं करता है। यह व्यवहार पहले उल्लिखित encrypted? और decryptable? विधियों के अनुकूल नहीं है। अभी मेरे पास एन्क्रिप्टेड का पता लगाने के लिए कई हैक हैं, लेकिन डिक्रिप्ट करने योग्य मेल नहीं हैं, लेकिन मैं इसे सभी मामलों में काम नहीं कर सकता।

UI में डिक्रिप्टेबल और एन्क्रिप्टेड के बीच अंतर न करने के बारे में आप क्या सोचते हैं? गुम जीपीजी संदेश शीर्षलेख, ओसीसी जैसे स्पष्ट मामलों को छोड़कर।

हम ज़माद में कार्यान्वयन और एकीकरण की उम्मीद कब कर सकते हैं? क्या कार्यान्वयन एक विशिष्ट रिलीज के लिए योजनाबद्ध है?

कोई खबर?

मुझे लगता है कि जो लोग इस प्लगइन के विकास को आगे ला सकते हैं उनके दिमाग में अन्य चीजें हैं लेकिन इस मुद्दे पर उत्तरों की जांच कर रहे हैं।
यदि आप इस पर उनका ध्यान आकर्षित करना चाहते हैं, तो आप उन्हें एक ईमेल लिख सकते हैं: [email protected] - मैंने पहले ही ऐसा कर लिया है - या उन्हें एक दोस्ताना ट्वीट @ubernauten भेजें

@hatscher देरी के लिए खेद है; जैसा कि @0xErnie ने अनुमान लगाया था कि मेरे पास वर्तमान में करने के लिए अन्य चीजें हैं, लेकिन यह सुविधा अभी भी हमारे रडार पर है। कृपया ध्यान दें कि मैं वर्तमान में इस एकल पर काम कर रहा हूं, न कि ज़माद, इंक. टीम के हिस्से के रूप में और बिना किसी बाहरी संस्थापक के। तो इसमें कुछ समय लग सकता है।

जहां तक ​​अवरोधकों की बात है, यहां @thorsteneckel के लिए एक प्रश्न खुला है, साथ ही एक निजी प्रश्न है कि हम इसके UI घटक से कैसे निपटेंगे। बेझिझक उससे संपर्क करें, अगर आप इसे आगे बढ़ाने के लिए जुड़ना चाहते हैं, तो @hatscher! मुख्य अवरोधक मेरे समय की कमी है, हालांकि।

देर से प्रतिक्रिया के लिए क्षमा करें, विशेष रूप से आपको @luto ! मैं इसे वह समय और ध्यान नहीं दे सकता जिसकी वर्तमान में आवश्यकता है। मैं अब से 2 सप्ताह में इसे संबोधित करने की योजना बना रहा हूं।

कोई खबर? हमें चाहिए ये फीचर...

@hatscher हममें से बहुतों को इसकी आवश्यकता है :) लेकिन आखिरकार, हर कोई जो सुविधा पर काम कर रहा है (@luto) स्वेच्छा से करता है :) अगर इसकी वास्तविक व्यावसायिक आवश्यकता है, तो मुझे लगता है कि दान करने से (या तो कुछ आटा या काम) ड्राइव करने में मदद प्रगति को आगे बढ़ाएं। दुर्भाग्य से मेरे पास योगदान करने का समय नहीं है, इसलिए मेरे पास केवल आशा और धैर्य है :P

योगदान के बारे में बात करना: विकास की वर्तमान स्थिति को पीआर के रूप में प्रस्तुत करने के बारे में कैसे अन्य लोग शामिल हो सकते हैं यदि उन्हें लगता है कि वे योगदान दे सकते हैं?

रूबी और सामान्य रूप से दोनों में जीपीजी-एपीआई की दुखद स्थिति को देखते हुए नया जीपीजी जंग कार्यान्वयन देखने लायक हो सकता है।

नमक की एक अनाज के साथ:

बाइंडिंग जल्द ही आ रही है!

क्या पीजीपी और एस/एमआईएमई एकीकरण के संबंध में कोई खबर है? मैं भी एक राशि दान करना चाहूंगा क्योंकि मुझे इस सुविधा की तत्काल आवश्यकता है ।

क्या वास्तव में आगामी संस्करणों की नियोजित सुविधाओं के साथ एक सूची है?

हाय @ हत्शेर ,
हमें S/MIME की भी आवश्यकता है और लागत के बारे में Zammad के साथ बातचीत कर रहे हैं। क्या हम एक-दूसरे से बात करना चाहते हैं ताकि हम एकीकरण की लागतों को साझा कर सकें? शायद मुझे सिर्फ एक ईमेल भेजें (अंतिम नाम पर पहला नाम)।

ईमेल आ रहा है ;-)

हम वर्तमान में ऐसे अन्य लोगों की तलाश कर रहे हैं जो इस सुविधा के लिए निधि देने के इच्छुक हैं (शायद एक पैकेज के रूप में S/MIME एन्क्रिप्शन के साथ भी)। कृपया मुझसे संपर्क करें यदि आप अंतिम नाम .de पर मेरे पूर्व नाम में रुचि रखते हैं। मैं जाँच करूँगा और देखूँगा कि कितने इच्छुक लोग हैं ताकि हम केवल लागतों को साझा कर सकें।

@martinseener यह सुनकर बहुत अच्छा लगा कि आपने इस सुविधा के लिए धन सुरक्षित करने का प्रयास किया। क्या आप हुई प्रगति या आपके द्वारा प्रभावित समस्याओं को साझा कर सकते हैं? पीजीपी समर्थन वर्तमान में ज़माद को स्थानांतरित करने के संबंध में निर्णय ले रहा है या तोड़ रहा है, इसलिए किसी भी अंतर्दृष्टि की सराहना की जाएगी।

क्षमा करें, लेकिन इस समय हम इस विषय पर कोई जानकारी साझा नहीं कर सकते।
जैसे ही Zammad-Core के लिए कुछ आगे बढ़ेगा हम इस मुद्दे को तदनुसार अपडेट करेंगे।

कई महीनों के आपके प्रतिक्रिया समय और इस मुद्दे पर पिछली चर्चाओं को देखते हुए, मैं यह निष्कर्ष निकाल रहा हूं कि जमाद को पीजीपी समर्थन जोड़ना आपकी प्राथमिकता नहीं है या ऐसा बिल्कुल भी नहीं होगा। (भविष्य में आने वाले किसी भी व्यक्ति के लिए इसे यहां संक्षेप में प्रस्तुत करें और पूरी चर्चा को पढ़ना नहीं चाहते हैं।)

अरे @rixx - तुम सही हो। वर्तमान में हम अपनी प्राथमिकता स्कीमा के आधार पर कार्यों पर काम कर रहे हैं:

पहला: समर्थन / कस्टम विकास
ये वे लोग हैं जो ज़माद को फ़ंड दे रहे हैं और वे सुविधाएँ जो हम जारी करते हैं। ज़माद आज उनके बिना यहाँ नहीं होते। उनका होना वास्तव में हमारे लिए बहुत मायने रखता है और प्रोत्साहित करता है कि हम सही रास्ते पर हैं।

दूसरा: 80% सुविधाएँ / मुद्दे
हम अपने ग्राहकों के समर्थन से जो खाली समय प्राप्त करते हैं, वह उत्पाद में 100% खर्च होता है। हमारे लिए यह महत्वपूर्ण है कि हम अपने उपयोगकर्ता आधार के किसी भी उपयोगकर्ता के साथ समान रूप से निष्पक्ष रहें। हालाँकि, जैसे ही विवरण की बात आती है, हमें एक पक्ष के पक्ष में दूसरे पक्ष के पक्ष में अधिक से अधिक निर्णय लेने की आवश्यकता होती है। इसलिए हम केवल उन सुविधाओं और मुद्दों पर काम करते हैं जो हमारे 80% उपयोगकर्ता आधार को प्रभावित कर रहे हैं। इस तरह हम यह सुनिश्चित कर सकते हैं कि हमारे उपयोगकर्ता आधार का अधिकांश हिस्सा हमारे द्वारा पेश किए गए परिवर्तनों से लाभान्वित हो।

तीसरा: व्यक्तिगत रुचि
यहाँ ज़म्मद में हर कोई व्यक्तिगत हित के कार्यों पर समय बिताने के लिए स्वतंत्र है। यदि आप अपने आस-पास फिर से देखें तो आप देखेंगे कि हम उन मुद्दों और प्रश्नों का उत्तर देते हैं जो वित्त पोषित या सर्वाधिक प्रासंगिक परिवर्तनों की श्रेणी में नहीं आते हैं। ऐसा इसलिए है क्योंकि हम वास्तव में परवाह करते हैं और लोगों की मदद करने का आनंद लेते हैं। हालाँकि, ये ज्यादातर छोटे कार्य हैं क्योंकि वर्तमान में खाली समय बहुत सीमित है - दुर्भाग्य से।

अब विषय पर वापस जाने के लिए: पीजीपी वर्तमान में ऊपर सूचीबद्ध किसी भी श्रेणी में नहीं आता है। इसलिए आप सही कह रहे हैं कि यह वर्तमान में हमारे लिए कोई उच्च प्राथमिकता नहीं है। हालांकि, आप गलत हैं जब आप कह रहे हैं कि पीजीपी बिल्कुल नहीं होगा। पीजीपी की हमारे लिए तुलनात्मक रूप से उच्च प्राथमिकता है, यह वास्तव में सार्वजनिक रोडमैप के लिए हमारे आंतरिक मसौदे पर है जिसमें केवल सबसे प्रासंगिक परिवर्तन शामिल हैं।
तो पीजीपी का समय अभी नहीं आया है लेकिन निश्चित रूप से आएगा। प्राथमिकता स्कीमा के आधार पर - जल्दी या बाद में।
आपके सारांश से जो मुझे याद आ रहा है वह यह है कि पीजीपी विकास वास्तव में हमारे समर्थन से @luto द्वारा सामुदायिक प्रयास के रूप में शुरू किया जा चुका है (धन्यवाद फिर से @luto !)। दुर्भाग्य से प्राथमिकता स्थानांतरित हो गई और परिवर्तन वर्तमान में पुराना है। हालांकि, हर किसी के पास चीजों को लेने और उस पर काम करना जारी रखने का ज्ञान और क्षमता है, निश्चित रूप से हमारे द्वारा समर्थित होगा!

एन्क्रिप्टेड संचार के समग्र विषय में रुचि रखने वाले किसी भी व्यक्ति के लिए भी खबर है: barzahlen.de पर @martinseener के आसपास के महान लोगों ने S/MIME संचार (#1961) के विकास को वित्त पोषित किया - जो जल्द ही शुरू हो जाएगा।

यदि आप इस चर्चा को गहरा करने में रुचि रखते हैं या योगदान भी देते हैं तो बेझिझक एक सूत्र खोलें या सामुदायिक बोर्ड में मुझे पीएम करें और इस मुद्दे को विषय पर रखें।

"एस/एमआईएमई संचार" के बारे में कोई खबर?

अगर आपको पूछना है, तो कृपया कम से कम सही जगह का उपयोग करें: https://github.com/zammad/zammad/issues/1961

क्षमा करें, पिछले महीनों में प्रतिक्रिया न होने के कारण मैं इस मुद्दे को केवल योगदानकर्ताओं तक ही सीमित कर रहा हूं।
यह शोर को कम करने के लिए है और हमें मुद्दों पर ध्यान केंद्रित करने में मदद करता है।

अगर हमारे पास इस पर कोई अपडेट है, तो हम इस मुद्दे को उसी के अनुसार अपडेट करेंगे।

जैसा कि आपने #1961 में देखा होगा, हमने S/MIME समर्थन जोड़ा है और इसे Zammad के आगामी संस्करण 3.4 के साथ जारी करेंगे 🎉 इसे प्रायोजित करने और इसलिए इसे संभव बनाने के लिए barzahlen.de पर @martinseener को बहुत-बहुत धन्यवाद
दुर्भाग्य से हमारे पास अभी भी पीजीपी समर्थन जोड़ने के लिए आवश्यक संसाधन नहीं हैं। हम कुछ चीजों का परीक्षण करने के बारे में सोच रहे थे लेकिन अभी तक मौका नहीं मिला है। इसलिए मैं आपको यहां एक संक्षिप्त अपडेट देना चाहता हूं।
हालांकि एस/एमआईएमई एकीकरण सुरक्षित मेलिंग को संभालने के लिए लगभग पूर्ण "ढांचा" प्रदान करता है और चीजों को एकीकृत/निर्माण करने के तरीके पर एक अच्छा संदर्भ कार्यान्वयन प्रदान करता है। अभी भी @luto द्वारा Uberspace fork पर किए गए महान प्रारंभिक कार्य हैं। अगर कोई इस पर मौका लेने को तैयार है तो हमें हर संभव मदद करने में खुशी होगी। सामुदायिक बोर्ड में बस एक सूत्र खोलें और मेरा उल्लेख करें।

नई जानकारी उपलब्ध होने पर हम आपको अपडेट रखते हैं - वादा किया ✌️