New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PGP #220
Comments
+1 for S/MIME Support |
Okay, I've changed the title. The best would of course if it would offer both things. |
I would appreciate to have to possiblity to send and recieve X.509 encrypted mails. |
YES, it would be very nice to be able to send and receive X.509 signed or encrypted mails. |
So X.509 encrypted mails are S/MIME mails. I personally would like PGP more (also because it is more widespread), but this issue is about both systems. 😃 |
I'd add encrypted notifications to the wishlist - therefore users need to be able to add there public key to their profile. FYI: A nice plugin with such functionality exists for redmine: https://github.com/C3S/redmine_openpgp |
This gem seems to be not really maintained (last commit ), but there are multiple others. Personally I'd say this gem has the most recent commit. |
Today we had the first customer request asking for PGP-Support because she did not want to request her bank details via an unencrypted connection. Therefor +1 |
+1. |
Nowadays e-mail encryption is a must. The General Data Protection Regulation (GDPR) requires Privacy by Design and by Default and according to the state of the art. |
Technically this might be easy to solve by integrating the p≡p engine (pretty easy privacy). |
+1 |
+1 |
+1 We would like to GnuPG sign all outgoing ticket emails after a very ugly case of faking our email to rob our customers. |
Maybe PeP could be integrated as it is a easy and usable solution for PGP encryption. |
I also think it would be a great feature to send signed emails. This would give some degree of confidence for the recipient, that the address is real and can be trusted. Next step would be to fully encrypt the message. |
Hi @luto - sounds good! Things that are required for a merge are:
We already looked at some Ruby gems that provide an API to the gpg CLI binary. As far as I remember none of them looked really promising. Please make sure to rely only on maintained/quality dependencies since this is a critical point. Functionality should include all variations of signing, verifying and en-/decryption of sending and receiving mails 🤓 There should be a nice admin interface to manage public and private keys. Feel free to contact us at support@zammad.com to ask any questions you have and get our support on this. We are more than happy to receive yours 💪 Let's do it the Zammad way 🏎 |
We also got the first customer that requires such communication, so i also vote for this one. Is there already any progress? I'd also like to help testing a beta. |
@martinseener afaik this is not on the roadmap of the Zammad team. We're currently planning to implement this on our own. If you'd like to chip to, so we can get it done faster and you can serve your customer, feel free reach out via the email-address on my github profile. |
@thorsteneckel I'm currently prototyping an implementation for receiving mails in two parts:
A couple of questions:
Also, a general question: I hope that this issue is the right place to ask implementation questions. If not, please point me to another, preferably public, one :) Thanks! |
Hi @luto - I'm currently writing my thoughts about this down. Since it's a rather big and important topic it takes some time. I try to get it done by end of the week. Thanks for your understanding. |
Small update: |
@thorsteneckel Thanks for taking the time! Looking forward to your write up. :) |
Hi @luto, glad to hear that! I like to have the coordination in this issue as you proposed. So it will be transparent and we can re-use the shared information for a technical documentation. You can refer to this issue in your working branch of your fork and it will get referenced here. Please create a Pull Request after the changes are complete. In the meantime I will check out your branch and see the changes. Regarding your questions: You are totally on the right path. I'll write some things down and answer your questions on the way. General developmentIn our experience test driven development (with RSpec) works best for this kind of tasks. It's up to you how you approach it but we will definitivly need a comprehensive test suite for the functionality. Therefore I will provide you with a RSpec helper to ease testing and support you on the way the best I can. I will add it to the Postmaster::PreFilter
After the registration is done Zammad will execute the filter for each incomming mail. PGP message classSince we will only implement PGP at this point we have to make sure that we won't add obstacles for adding S/MIME later. Additionally it might be necessary in the future to support PGP on other channels than email only. Having this in mind will ensure that the backend and API we design will be easy to test and integrate. Following my proposal (open for discussion): There should be a class called instance = PgpMessage.new(email_content) The instance should provide the following interface:
PGP interfaceTo be honest I haven't found any gem that I like to have as a dependency. They all look unmaintained, complex or need C compilation of extensions. It might be worth to try if we can't just access the PGP CLI. What do you think? PgpMessage integration in the Postmaster::PreFilter for decryptionThe PgpMessage class can then be used in the mail[:'x-zammad-article-preferences']['decryption_key'] = instance.key
... I think the following metadata should be sufficient:
supported variations of decryptable messagesThe PgpMessage class should be able to handle (at least?) the following combinations and variations of incomming PGP messages:
Do you have enough example mails already? We have to have a comprehensive list of test cases to cover various cases which can be extended easily in the future. sending encryted messagesSince Zammad only supports sending HTML emails we only need to cover sending The place where Zammad builds an email from given attributes is in I think that there should be no option to send unencrypted mails once PGP is configured and the receipient supports it. We need to clarify this but until then this should be the way to go. Admin interfaceThis should be isolated from the core functionality and will be described later. I think you'll need our support on this. I will discuss it internally and let you know how we approach it. ConclusionThis should be sufficient by now and point in the right direction. We probably will reach some spots where we have to realign and cover other cases but let them arise first. I'm looking forward to see and review your changes 🤓 Thanks for your support 🚀 |
The PGP CLI is not stable and should, according to GPG, not be used as an API. I've had success with using ruby-gpgme so far, so that's the route I'd like to follow for now. Given that as far as I know GPG does not have an API, but only C-level libraries, I don't think we'll get away without any C extensions.. except for a re-implementation of GPG in ruby maybe, but I don't know of any. |
Thanks for making it clear. I wasn't aware of that. Sounds good to me then. It's a bit concerning that their builds are failing but I will have a look at it. |
Any news? |
I have a feeling that those who could bring forward the development of this plugin have other stuff on their mind but checking the replies on this issue. |
@hatscher sorry for the delay; as @0xErnie guessed I've currently got other stuff to do, but this feature is still on our radar. Please note that I am currently working on this solo, not as part of the Zammad, Inc. team and without any external founding. So this can take a while. As for blockers, there is one question for @thorsteneckel open here, as well as a private one about how we're going to tackle the UI compontent of this. Feel free to contact him, if you'd like to chip in to move this forward, @hatscher! The main blocker is my lack of time, though. |
Sorry for the late response, especially to you @luto ! I can't give this the time and attention it needs currently. I plan to address this in 2 weeks from now. |
Any news? We need this feature ... |
@hatscher many of us need it :) But after all, everybody who's working on the feature (@luto) does it voluntarily :) If there's real commercial need for it, I guess donating (either some dough or work) would help to drive forward the progress. Unfortunately I don't have the time to contribute, so all I'm left with is hope and patience :P Talking about contributions: How about submitting the current state of development as PR so other could join if they feel like they could contribute? |
Given the sad state of GPG-APIs both in ruby and in general the new GPG rust implementation might be worth a look. |
With a grain of salt:
|
Are there any news regarding PGP and S/MIME integration? I would also like to donate an amount because I urgently need this feature. Is there actually a list with the planned features of the upcoming versions? |
Hi @hatscher , |
E-Mail ist unterwegs ;-) |
We're currently searching for other People who are willing to fund this feature (maybe also together with the S/MIME encryption as a package). Please contact me if you're interested at my forename at lastname .de. I will check and see how many willing people are there so we can just share the costs. |
@martinseener Great to hear that you tried to secure funding for this feature. Could you share the progress made or the problems you hit? PGP support is currently making-or-breaking a decision regarding a move to Zammad, so any insight would be appreciated. |
Sorry, but at this moment we can't share any information on this topic. |
Looking at your response time of several months and the previous discussions on this issue, I'm concluding that adding PGP support to Zammad is not a priority for you or will not happen at all. (Just summing it up here for anybody who comes along in the future and doesn't want to read the entire discussion.) |
Hey @rixx - you're right. We currently working on tasks based on our priority schema: 1st: support / custom development 2nd: 80% features / issues 3rd: Personal interest Now to get back topic: PGP currently doesn't fall in any of the categories listed above. That's why you're right when saying that it's currently no high priority for us. However, you're wrong when you're saying that PGP won't happen at all. PGP has a comparably high priority for us, it's actually on our internal draft for the public roadmap which includes only the most relevant changes. There's also news for anyone interested in the overall topic of encrypted communication: The great folks around @martinseener at barzahlen.de funded the development of S/MIME communication (#1961) - which soon will be started. If you're interested in deepen this discussion or even contribute feel free to open a thread or PM me over at the community board and keep this issue on topic. |
Any news about "S/MIME communication" ? |
If you have to ask, please at least use the right place: #1961 |
Sorry, because of missing feedback in the last months I'm limitting this issue to contributors only. If we have any updates on this, we'll update this issue accordingly. |
As you've might seen over at #1961 we've added S/MIME support and will release it with the upcoming version 3.4 of Zammad 🎉 Huge thanks to @martinseener over at barzahlen.de for sponsoring it and therefore making it possible 🙌 We keep you updated as new information is available - promised ✌️ |
Closed in favor of #4679. Stay tuned! |
It would be nice if mails with users could be PGP-encrypted ans users could send the service PGP-encrypted mails.
Especially for security aware/tech companies, this would be a unique feature.
The text was updated successfully, but these errors were encountered: