Zammad: PGP

+1 untuk Dukungan S/MIME

Oke, saya telah mengubah judul. Yang terbaik tentu saja jika menawarkan kedua hal tersebut.

Saya akan menghargai kemungkinan untuk mengirim dan menerima email terenkripsi X.509.

YA, akan sangat menyenangkan jika dapat mengirim dan menerima email bertanda tangan atau terenkripsi X.509.

Jadi email terenkripsi X.509 adalah email S/MIME. Saya pribadi ingin PGP lebih (juga karena lebih luas), tetapi masalah ini adalah tentang kedua sistem. 😃.

Saya akan menambahkan pemberitahuan terenkripsi ke daftar keinginan - oleh karena itu pengguna harus dapat menambahkan kunci publik di sana ke profil mereka.

FYI: Plugin yang bagus dengan fungsi seperti itu ada untuk redmine: https://github.com/C3S/redmine_openpgp

Permata ini tampaknya tidak benar-benar dipertahankan (komit terakhir), tetapi ada beberapa lainnya . Secara pribadi saya akan mengatakan permata ini memiliki komit terbaru.

Hari ini kami menerima permintaan pelanggan pertama yang meminta Dukungan PGP karena dia tidak ingin meminta detail banknya melalui koneksi yang tidak terenkripsi. Oleh karena itu +1

+1.
Kami bekerja dengan komunitas IT SEC dan menerima banyak email terenkripsi PGP yang tidak dapat kami buka di Zammad, jadi kami harus mengekspor & mendekripsi, ini adalah alur kerja yang luar biasa. +1 untuk mendukung PGP dan mungkin S/MIME Mails di Zammad :)

Saat ini enkripsi e-mail adalah suatu keharusan. Peraturan Perlindungan Data Umum (GDPR) mewajibkan Privasi berdasarkan Desain dan Default serta sesuai dengan keadaan seni.

Secara teknis ini mungkin mudah diselesaikan dengan mengintegrasikan mesin p≡p (privasi yang cukup mudah).

+1
Kami sering menerima email terenkripsi. Mengekspor dan mendekripsi tiket terenkripsi secara manual itu menyakitkan, dan kemudian kami bahkan tidak dapat menjawab tiket melalui sistem tiket.

+1
Tanpa PGP/GPG saya tidak bisa bermigrasi dari OTRS ke Zammad. Saya memiliki banyak tiket terenkripsi dengan gnupg di OTRS lama saya.

+1

Kami ingin GnuPG menandatangani semua email tiket keluar setelah kasus yang sangat buruk memalsukan email kami untuk merampok pelanggan kami.

Mungkin PeP dapat diintegrasikan karena merupakan solusi yang mudah dan dapat digunakan untuk enkripsi PGP.

Saya juga berpikir itu akan menjadi fitur hebat untuk mengirim email yang ditandatangani. Ini akan memberikan beberapa tingkat kepercayaan bagi penerima, bahwa alamat itu nyata dan dapat dipercaya.

Langkah selanjutnya adalah mengenkripsi pesan sepenuhnya.

@martini @monotek kami berpikir untuk menangani bagian GPG ini sendiri, secara internal. Apakah ada batasan untuk menggabungkan ini, jika kita melakukannya? fungsi apa pun yang ingin Anda lihat atau butuhkan?

Hai @luto - kedengarannya bagus! Hal-hal yang diperlukan untuk penggabungan adalah:

• Tes, sebaiknya RSpec
• Dokumentasi
• Dokumentasi kode API
• Kode QAd melalui konfigurasi rubocop dan coffeelint kami

Kami telah melihat beberapa permata Ruby yang menyediakan API ke biner gpg CLI. Sejauh yang saya ingat tidak satupun dari mereka tampak benar-benar menjanjikan. Harap pastikan untuk hanya mengandalkan dependensi yang dipertahankan/kualitas karena ini adalah titik kritis.
Implementasi khusus dimungkinkan tetapi tetap mempertimbangkan ekstensibilitas dan pemeliharaan. Jangan masukkan semua logika ke dalam modul tetapi buat kelas lib untuknya. Hormati prinsip tanggung jawab tunggal.

Fungsionalitas harus mencakup semua variasi penandatanganan, verifikasi, dan en-/dekripsi pengiriman dan penerimaan surat
Penanganan pesan masuk harus dilakukan sedini mungkin agar konten dapat diakses di komponen lain.
Penanganan pesan keluar harus dilakukan selambat-lambatnya untuk dapat mengakses konten di komponen lain.

Harus ada antarmuka admin yang bagus untuk mengelola kunci publik dan pribadi.

Jangan ragu untuk menghubungi kami di [email protected] untuk mengajukan pertanyaan apa pun yang Anda miliki dan mendapatkan dukungan kami dalam hal ini. Kami sangat senang menerima milik Anda Mari kita lakukan dengan cara Zammad

Kami juga mendapat pelanggan pertama yang membutuhkan komunikasi seperti itu, jadi saya juga memilih yang ini. Apakah sudah ada kemajuan? Saya juga ingin membantu menguji versi beta.

@martinseener afaik ini tidak ada di peta jalan tim Zammad. Saat ini kami berencana untuk menerapkannya sendiri. Jika Anda ingin melakukan chip, sehingga kami dapat menyelesaikannya lebih cepat dan Anda dapat melayani pelanggan Anda, silakan hubungi melalui alamat email di profil github saya.

@thorsteneckel Saat ini saya sedang membuat prototipe implementasi untuk menerima email dalam dua bagian:

1. mendekripsi email di Postmaster::PreFilter : mengatur pesan yang didekripsi sebagai konten; buang yang asli; simpan kunci dekripsi yang digunakan dalam metadata
2. di Postmaster::PostFilter buat objek GpgCryptoInfo , lampirkan ke Article ; menyimpan informasi seperti kunci dekripsi yang digunakan dan status tanda tangan secara permanen

Beberapa pertanyaan:

• menurut Anda ini harus diimplementasikan menggunakan API filter itu? Atau haruskah ini di-hardcode dalam Channel::EmailParser ?
• apakah ada pelanggan Postmaster::PreFilter , yang memerlukan akses ke konten pesan yang didekripsi? Dalam hal ini implementasi hardcode atau Postmaster::EarlyPreFilter diperlukan.
• apakah ada informasi kecuali kunci yang digunakan untuk mengenkripsi/mendekripsi/menandatangani/memverifikasi serta status tanda tangan dari email yang diterima yang ingin Anda simpan secara permanen?

Juga, pertanyaan umum: EmailParser atau filter tampaknya menjadi tempat yang tepat untuk _decrypt_ mail; dapatkah Anda memikirkan tempat yang "sempurna" untuk mengenkripsi mereka?

Saya berharap bahwa masalah ini adalah tempat yang tepat untuk mengajukan pertanyaan implementasi. Jika tidak, tolong arahkan saya ke yang lain, lebih disukai publik, satu :) Terima kasih!

Hai @luto - Saat ini saya sedang menulis pemikiran saya tentang ini. Karena ini adalah topik yang agak besar dan penting, ini membutuhkan waktu. Saya mencoba untuk menyelesaikannya pada akhir minggu. Terima kasih atas pengertian Anda.

Pembaruan kecil: filter Postmaster::PreFilter dipesan. Saat ini saya menempatkan milik saya tepat setelah IdentifySender , jadi saya dapat mengetahui kunci gpg mana yang harus dicoba. Mengetahui hal itu, filter tampaknya menjadi tempat yang tepat untuk mendekripsi untuk saya.

@thorsteneckel Terima kasih telah meluangkan waktu! Menantikan untuk menulis Anda. :)

Hai @luto , senang mendengarnya! Saya ingin memiliki koordinasi dalam masalah ini seperti yang Anda usulkan. Sehingga akan transparan dan kami dapat menggunakan kembali informasi yang dibagikan untuk dokumentasi teknis. Anda dapat merujuk ke masalah ini di cabang kerja garpu Anda dan itu akan dirujuk di sini. Silakan buat Pull Request setelah perubahan selesai. Sementara itu saya akan memeriksa cabang Anda dan melihat perubahannya.
Kita harus memindahkan fungsionalitas S/MIME ke masalah terpisah karena kita tidak akan mengimplementasikannya sekarang.

Mengenai pertanyaan Anda: Anda benar-benar berada di jalan yang benar. Saya akan menuliskan beberapa hal dan menjawab pertanyaan Anda di jalan.

Perkembangan umum

Dalam pengalaman kami, pengembangan yang didorong oleh pengujian (dengan RSpec) berfungsi paling baik untuk tugas semacam ini. Terserah Anda bagaimana Anda mendekatinya, tetapi kami pasti akan membutuhkan rangkaian pengujian yang komprehensif untuk fungsionalitasnya. Oleh karena itu saya akan memberi Anda bantuan RSpec untuk memudahkan pengujian dan mendukung Anda dengan cara terbaik yang saya bisa. Saya akan menambahkannya ke brach develop di hari-hari berikutnya. Anda harus menggunakan cabang ini sebagai basis Anda karena ini adalah cabang kerja kami juga. Itu akan digabung menjadi master dan menggantikan stabil di masa depan.

Kepala Pos::PraFilter

Postmaster::PreFilter s adalah tempat yang tepat. Anda dapat mempengaruhi waktu eksekusi dengan awalan nomor atas nama registrasi filter . Angka yang lebih rendah akan dieksekusi lebih awal .
Untuk sistem yang sudah diinisialisasi, migrasi yang menambahkan pengaturan juga diperlukan .
Saya akan mengusulkan nama sesuatu seperti app/models/channel/filter/decrypt.rb - tetapi pada akhirnya terserah Anda.

Setelah registrasi selesai, Zammad akan menjalankan filter untuk setiap email yang masuk.

Kelas pesan PGP

Karena kami hanya akan mengimplementasikan PGP saat ini, kami harus memastikan bahwa kami tidak akan menambahkan hambatan untuk menambahkan S/MIME nanti. Selain itu, di masa mendatang mungkin perlu mendukung PGP di saluran lain selain email saja. Mengingat hal ini akan memastikan bahwa backend dan API yang kami desain akan mudah diuji dan diintegrasikan. Mengikuti proposal saya (terbuka untuk diskusi):

Seharusnya ada kelas bernama PgpMessage yang terletak di file lib/pgp_message.rb . Kelas ini mengambil satu argumen yang diperlukan yang akan menjadi (mungkin) pesan terenkripsi string/konten email. Contoh:

instance = PgpMessage.new(email_content)

Instance harus menyediakan antarmuka berikut:

• #tertanda?
• #verifikasi?(tanda tangan) # tanda tangan adalah opsional dan dapat berupa tanda tangan eksternal dari misalnya lampiran
• #signature_error
• #terenkripsi?
• #dapat dideskripsikan?
• #dekripsi
• #kunci
• #dekripsi_kesalahan
• #enkripsi( public_key(s) )
• #tanda

antarmuka PGP

Sejujurnya saya belum menemukan permata yang ingin saya miliki sebagai ketergantungan. Semuanya terlihat tidak terawat, rumit, atau membutuhkan kompilasi ekstensi C. Mungkin patut dicoba jika kita tidak bisa mengakses PGP CLI saja. Bagaimana menurut anda?

Integrasi PgpMessage di Postmaster::PreFilter untuk dekripsi

Kelas PgpMessage kemudian dapat digunakan di Postmaster::PreFilter untuk menginisialisasi sebuah instance dan memeriksa relevansi pesan. Jika ini adalah pesan terenkripsi PGP, kami dapat melanjutkan menggunakan metode lain untuk mengekstrak data yang kami butuhkan dan menimpa konten untuk body dan attachments dalam hash mail yang diberikan.
Selain itu kita harus menyimpan beberapa informasi meta (seperti yang sudah Anda nyatakan) di artikel yang akan dibuat dengan mengatur header x-zammad-article-preferences :

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

Saya pikir metadata berikut sudah cukup:

• kunci_dekripsi <- kunci
• decryption_error <- decryption_error (jika ada)
• pesan_enkripsi <- mail['body']
• signature_status <- diverifikasi?
• signature_error <- signature_error (jika ada)

variasi yang didukung dari pesan yang dapat didekripsi

Kelas PgpMessage harus dapat menangani (setidaknya?) kombinasi dan variasi berikut dari pesan PGP masuk:

• terenkripsi
• tertanda
• dienkripsi + ditandatangani
• Di barisan
• Lampiran

Apakah Anda sudah memiliki cukup banyak contoh surat?

Kita harus memiliki daftar kasus uji yang komprehensif untuk mencakup berbagai kasus yang dapat diperluas dengan mudah di masa depan.

mengirim pesan terenkripsi

Karena Zammad hanya mendukung pengiriman email HTML , kami hanya perlu mencakup pengiriman detached email PGP.

Tempat Zammad membuat email dari atribut yang diberikan ada di app/models/channel/email_build.rb dalam metode self.build . Ini harus diperluas untuk menggunakan kelas PgpMessage untuk membuat instance dengan atribut body yang diberikan dan menggunakan metode encrypted dan signed untuk membuat PGP terenkripsi dan isi isi dan lampiran yang ditandatangani.
Untuk melakukan ini, diperlukan untuk mencari kunci publik dari alamat email penerima. Bagaimana pengguna dapat menyimpan kunci mereka (di profil mereka) belum jelas. Saya akan membahas ini secara internal dan memberi tahu Anda.

Saya pikir seharusnya tidak ada opsi untuk mengirim email yang tidak terenkripsi setelah PGP dikonfigurasi dan penerima mendukungnya. Kami perlu mengklarifikasi ini tetapi sampai saat itu harus menjadi cara untuk pergi.

Antarmuka admin

Ini harus diisolasi dari fungsionalitas inti dan akan dijelaskan nanti. Saya pikir Anda akan membutuhkan dukungan kami dalam hal ini. Saya akan membahasnya secara internal dan memberi tahu Anda bagaimana kami mendekatinya.

Kesimpulan

Ini seharusnya sudah cukup sekarang dan menunjukkan arah yang benar. Kami mungkin akan mencapai beberapa titik di mana kami harus menyelaraskan dan menutupi kasus-kasus lain tetapi biarkan mereka muncul terlebih dahulu.
Jangan ragu untuk mengajukan pertanyaan jika muncul.

Saya menantikan untuk melihat dan meninjau perubahan Anda

Terima kasih atas dukungan Anda
Thorsten

Sejujurnya saya belum menemukan permata yang ingin saya miliki sebagai ketergantungan. Semuanya terlihat tidak terawat, rumit, atau membutuhkan kompilasi ekstensi C. Mungkin patut dicoba jika kita tidak bisa mengakses PGP CLI saja. Bagaimana menurut anda?

PGP CLI tidak stabil dan menurut GPG, seharusnya tidak digunakan sebagai API. Saya telah berhasil menggunakan Ruby-gpgme sejauh ini, jadi itulah rute yang ingin saya ikuti untuk saat ini. Mengingat sejauh yang saya tahu GPG tidak memiliki API, tetapi hanya perpustakaan tingkat C, saya tidak berpikir kita akan lolos tanpa ekstensi C.. kecuali untuk implementasi ulang GPG di Ruby mungkin, tapi Saya tidak tahu apa-apa.

Terima kasih untuk membuatnya jelas. Saya tidak menyadari itu. Kedengarannya bagus untukku kalau begitu. Agak mengkhawatirkan bahwa bangunan mereka gagal tetapi saya akan melihatnya.

Hei! Seperti yang telah dibahas sebelumnya, masalah ini dimulai sebagai permintaan untuk fungsionalitas PGP. Kemudian kami menambahkan S/MIME juga. Namun karena keduanya diimplementasikan secara independen dan merupakan teknologi yang berbeda, kami memutuskan untuk memindahkan persyaratan S/MIME ke edisi baru # 1961. Jangan ragu untuk berlangganan di sana jika Anda tertarik dengan kemajuan apa pun. Diskusi harus dilakukan di dewan komunitas untuk menghindari kebisingan pada pelacak masalah. Terima kasih!

Oleh karena itu saya akan memberi Anda bantuan RSpec untuk memudahkan pengujian dan mendukung Anda dengan cara terbaik yang saya bisa. Saya akan menambahkannya ke pengembangan brach di hari-hari berikutnya.

@thorsteneckel ini sudah mendarat dan jika ya, di mana tepatnya? :)

@luto - maaf atas keterlambatannya - ini dia: https://github.com/zammad/zammad/commit/f2bf4cbd029bbfdc79888c188d2a29d1ebc5f27d

Anda hanya perlu menempatkan *filter_filename*_spec.rb di spec/models/channel/filter/ (seperti yang dilakukan untuk models/channel/filter/follow_up_merged.rb dan tambahkan , type: :channel_filter setelah nama kelas filter Anda.
Setelah itu Anda memiliki dua pembantu yang tersedia:

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

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

Parameter bernama channel adalah opsional dan tidak diperlukan dalam kasus Anda.

Terima kasih!
FYI: cabang tinggal di garpu kami sekarang. jangan ragu untuk mengomentari salah satu komit saat saya pergi. Itu akan membuat tinjauan akhir tetap mudah dan singkat untuk semua orang yang terlibat :)

Hai @luto - senang melihat Anda mengerjakan ini dengan kecepatan seperti itu. Saya perhatikan bahwa kode tersebut sepertinya tidak diperiksa dengan rubocop. Kami menggunakan rubocop dan coffeelint untuk memastikan panduan gaya Zammad untuk kedua jenis file. Bahkan ada konfigurasi filter pra-komit yang tersedia jika Anda ingin melakukan pemeriksaan secara otomatis. Beri tahu saya jika saya dapat memberi Anda informasi lebih lanjut tentang itu.

Oh, tentu saja. Saya memasang pengait dengan pre-commit install serta ekstensi yang cocok untuk editor saya . Lekukan telah diperbaiki melalui filter-branch , sehingga riwayatnya terlihat lebih bagus; semua pelanggaran lainnya diperbaiki dengan tangan. Polisi itu kebanyakan senang sekarang :)

Anda mungkin melihat a dengan pythonisme dalam kode. Sementara saya mencoba untuk meniru cara ruby ​​​​dalam melakukan hal-hal sebaik mungkin, saya masih seorang pria python dengan perdagangan ;) Tolong tunjukkan saja, jika mereka tampak mundur bagi Anda. Rubocop menangkap beberapa dari mereka :sweat_smile:

Bagus! Saya baru menyadari bahwa setidaknya ada satu jenis perubahan yang diterapkan yang tidak cocok dengan konfigurasi rubocop kami: Menggunakan unless alih-alih negatif if s. Jadi sepertinya rubocop Anda melakukan banyak hal di sini.

Oh pythonisms baik-baik saja untuk saya. Tidak ada yang perlu dikeluhkan sejauh ini

Hai @luto - Saya hanya ingin melihat status perkembangan saat ini tetapi memperhatikan bahwa tidak ada komit sejak 24 hari. Apakah ada sesuatu yang saya bisa lakukan?

Apakah ada sesuatu yang saya bisa lakukan?

memperbaiki proyek internal kami yang lain :wink: :grin:
Tidak ada pemblokir dalam batas-batas Zammad, hanya kekurangan waktu secara umum. Pekerjaan ini harus dilanjutkan minggu depan.

@thorsteneckel Saya agak terbentur. Gpg (atau setidaknya gpgme) tidak membedakan antara "email dienkripsi, tetapi tidak dapat didekripsi" dan "email dienkripsi dan semuanya baik-baik saja" dalam banyak kasus. Perilaku itu tidak kompatibel dengan metode encrypted? dan decryptable? yang diuraikan sebelumnya. Saat ini saya memiliki sejumlah peretasan untuk mendeteksi surat terenkripsi, tetapi tidak dapat didekripsi, tetapi saya tidak dapat membuatnya berfungsi dalam semua kasus.

Apa pendapat Anda tentang tidak membuat perbedaan antara yang dapat didekripsi dan dienkripsi di UI? Kecuali untuk kasus yang jelas seperti header pesan GPG yang hilang, ofc.

Kapan kita bisa mengharapkan implementasi dan integrasi di Zammad? Apakah implementasi direncanakan untuk rilis tertentu?

Ada berita?

Saya merasa bahwa mereka yang dapat memajukan pengembangan plugin ini memiliki hal-hal lain di pikiran mereka tetapi memeriksa balasan tentang masalah ini.
Jika Anda ingin mendapatkan perhatian mereka tentang hal ini, Anda dapat menulis email kepada mereka: [email protected] - Saya sudah melakukannya - atau kirimi mereka tweet ramah @ubernauten

@hatscher maaf atas keterlambatannya; seperti dugaan @0xErnie, saat ini saya memiliki hal lain yang harus dilakukan, tetapi fitur ini masih dalam radar kami. Harap dicatat bahwa saya sedang mengerjakan solo ini, bukan sebagai bagian dari tim Zammad, Inc. dan tanpa pendirian eksternal. Jadi ini bisa memakan waktu cukup lama.

Untuk pemblokir, ada satu pertanyaan untuk @thorsteneckel yang terbuka di sini, dan juga pertanyaan pribadi tentang bagaimana kami akan menangani komponen UI ini. Jangan ragu untuk menghubunginya, jika Anda ingin ikut serta untuk memajukan ini, @hatscher! Penghalang utama adalah kurangnya waktu saya.

Maaf atas keterlambatan respon, terutama untuk Anda @luto ! Saya tidak bisa memberikan waktu dan perhatian yang dibutuhkannya saat ini. Saya berencana untuk membahas ini dalam 2 minggu dari sekarang.

Ada berita? Kami membutuhkan fitur ini ...

@hatscher banyak dari kita yang membutuhkannya :) Tapi bagaimanapun juga, semua orang yang mengerjakan fitur (@luto) melakukannya secara sukarela :) Jika ada kebutuhan komersial yang nyata untuk itu, saya kira menyumbang (baik adonan atau pekerjaan) akan membantu untuk mengemudi memajukan kemajuan. Sayangnya saya tidak punya waktu untuk berkontribusi, jadi saya hanya punya harapan dan kesabaran :P

Berbicara tentang kontribusi: Bagaimana jika mengajukan status perkembangan saat ini sebagai PR sehingga orang lain dapat bergabung jika mereka merasa dapat berkontribusi?

Mengingat keadaan GPG-API yang menyedihkan baik di ruby ​​maupun secara umum, implementasi GPG rust yang baru mungkin layak untuk dilihat.

Dengan sebutir garam:

BINDING SEGERA DATANG!

Apakah ada berita tentang integrasi PGP dan S/MIME? Saya juga ingin menyumbangkan sejumlah uang karena saya sangat membutuhkan fitur ini.

Apakah sebenarnya ada daftar dengan fitur yang direncanakan dari versi yang akan datang?

Hai @hatscher ,
kami juga membutuhkan S/MIME dan sedang dalam pembicaraan dengan Zammad tentang biayanya. Apakah kami ingin berbicara satu sama lain sehingga kami mungkin dapat berbagi biaya untuk integrasi? Mungkin hanya mengirimi saya email (nama depan di nama belakang de).

Email sedang dalam perjalanan ;-)

Kami sedang mencari Orang lain yang bersedia mendanai fitur ini (mungkin juga bersama dengan enkripsi S/MIME sebagai satu paket). Silakan hubungi saya jika Anda tertarik dengan nama depan saya di nama belakang .de. Saya akan memeriksa dan melihat berapa banyak orang yang bersedia di sana sehingga kami dapat berbagi biaya.

@martinseener Senang mendengar bahwa Anda mencoba mendapatkan pendanaan untuk fitur ini. Bisakah Anda berbagi kemajuan yang dibuat atau masalah yang Anda hadapi? Dukungan PGP saat ini sedang mengambil keputusan untuk pindah ke Zammad, jadi setiap wawasan akan dihargai.

Maaf, tetapi saat ini kami tidak dapat membagikan informasi apa pun tentang topik ini.
Kami akan memperbarui masalah ini segera setelah sesuatu bergerak untuk Zammad-Core.

Melihat waktu tanggapan Anda selama beberapa bulan dan diskusi sebelumnya tentang masalah ini, saya menyimpulkan bahwa menambahkan dukungan PGP ke Zammad bukanlah prioritas bagi Anda atau tidak akan terjadi sama sekali. (Hanya meringkasnya di sini untuk siapa saja yang datang di masa depan dan tidak ingin membaca seluruh diskusi.)

Hei @rixx - Anda benar. Saat ini kami mengerjakan tugas berdasarkan skema prioritas kami:

1: dukungan / pengembangan khusus
Ini adalah orang-orang yang mendanai Zammad dan fitur-fitur yang kami rilis. Zammad tidak akan berada di sini hari ini tanpa mereka. Memiliki mereka sangat berarti bagi kami dan mendorong kami berada di jalur yang benar.

2: 80% fitur / masalah
Waktu luang yang kami peroleh dari dukungan pelanggan kami adalah menghabiskan 100% dalam produk. Penting bagi kami untuk bersikap adil kepada setiap pengguna basis pengguna kami. Namun, begitu sampai pada detailnya, ada semakin banyak keputusan yang perlu kita buat untuk mendukung satu pihak daripada yang lain. Oleh karena itu kami hanya mengerjakan fitur dan masalah yang memengaruhi 80% basis pengguna kami. Dengan cara ini kami dapat memastikan bahwa sebagian besar basis pengguna kami mendapat untung dari perubahan yang kami perkenalkan.

3: Kepentingan pribadi
Di sini, di Zammad, setiap orang bebas menghabiskan waktu untuk tugas-tugas yang menjadi minat pribadi. Jika Anda melihat sekeliling, Anda akan melihat bahwa kami menanggapi masalah dan pertanyaan yang tidak termasuk dalam kategori perubahan yang didanai atau paling relevan. Ini karena kami benar-benar peduli dan senang membantu orang. Namun, ini sebagian besar adalah tugas yang lebih kecil karena waktu luang saat ini sangat terbatas - sayangnya.

Sekarang untuk kembali ke topik: PGP saat ini tidak termasuk dalam salah satu kategori yang tercantum di atas. Itu sebabnya Anda benar ketika mengatakan bahwa saat ini tidak ada prioritas utama bagi kami. Namun, Anda salah ketika mengatakan bahwa PGP tidak akan terjadi sama sekali. PGP memiliki prioritas yang relatif tinggi bagi kami, ini sebenarnya ada di draft internal kami untuk roadmap publik yang hanya mencakup perubahan yang paling relevan.
Jadi waktu untuk PGP belum tiba tapi pasti akan datang. Tergantung pada skema prioritas - cepat atau lambat.
Apa yang saya lewatkan dari ringkasan Anda adalah fakta bahwa pengembangan PGP sebenarnya telah dimulai sebagai upaya komunitas oleh @luto dengan dukungan kami (terima kasih lagi @luto !). Sayangnya prioritas bergeser dan perubahan saat ini basi. Namun, semua orang dengan pengetahuan dan kemampuan untuk mengambil sesuatu dan terus mengerjakannya pasti akan didukung oleh kami!

Ada juga berita untuk siapa saja yang tertarik dengan topik keseluruhan komunikasi terenkripsi: Orang-orang hebat di sekitar @martinseener di barzahlen.de mendanai pengembangan komunikasi S/MIME (#1961) - yang akan segera dimulai.

Jika Anda tertarik untuk memperdalam diskusi ini atau bahkan berkontribusi, silakan buka utas atau PM saya di papan komunitas dan pertahankan topik ini.

Adakah berita tentang "komunikasi S/MIME" ?

Jika Anda harus bertanya, setidaknya gunakan tempat yang tepat: https://github.com/zammad/zammad/issues/1961

Maaf, karena umpan balik yang hilang dalam beberapa bulan terakhir, saya membatasi masalah ini hanya untuk kontributor.
Ini untuk mengurangi kebisingan dan membantu kita berkonsentrasi pada masalah.

Jika kami memiliki pembaruan tentang ini, kami akan memperbarui masalah ini sesuai dengan itu.

Seperti yang mungkin Anda lihat di #1961, kami telah menambahkan dukungan S/MIME dan akan merilisnya dengan Zammad versi 3.4 yang akan datang Terima kasih banyak kepada @martinseener di barzahlen.de untuk mensponsori dan karena itu memungkinkan 🙌
Sayangnya kami masih belum memiliki sumber daya yang diperlukan untuk menambahkan dukungan PGP juga. Kami berpikir untuk menguji beberapa hal tetapi belum memiliki kesempatan. Itu sebabnya saya ingin memberi Anda pembaruan singkat di sini.
Namun integrasi S/MIME menyediakan "kerangka" yang hampir lengkap untuk menangani pengiriman surat yang aman dan implementasi referensi yang bagus tentang bagaimana segala sesuatunya harus diintegrasikan/dibangun. Masih ada pekerjaan awal yang hebat yang dilakukan oleh @luto di fork Uberspace . Jika ada yang mau mengambil kesempatan itu kami senang untuk membantu dengan semua yang kami bisa. Buka saja utas di papan komunitas dan sebutkan saya.

Kami terus memperbarui Anda saat informasi baru tersedia - dijanjikan ️