Hey all, I would like to do some brainstorming here :) People use ticketing systems for a variety of purposes and I can relate with that, since those systems make organizing collective work load in groups, especially those who don’t meet everyday in person, a lot easier.

There are lot of ticketing systems around and I really like some of them, such as zammad, e.g. In recent days I heard several people discussing different workflows for there community organizations or other civil projects, where ticket systems could really provide some help for them. The problem with all ticketing systems is, that non of them provides a real ability for end-to-end encrypted (e2ee) communication, which apparently was a proper concern.

The main problem here is, that real e2ee has to be implemented via a client (desktop) app. Yes, zammad also provides some “support for pgp”, but the problem here is, that the pgp keys are stored on the server itself. So when the server gets compromised, the attacker will be able to just take the (d)encryption keys alongside with the actual encrypted messages. This obviously breaks the fundamental idea of e2ee, not having to trust the server itself for data confidentiality.

Thats why I think it needs a client side solution for this. Now I think there are two options here:

  1. Build a client app for an existing ticketing system
  2. Build a server applications, that can be talked to through existing (maybe modified) mail clients

I see pros and cons for both here. Pros:

  1. Building a client app for an existing ticketing service saves one the time to reinvent all the complex ticketing logic
  2. I don’t know anything about coding frontends (GUI’s, javascript, etc), I could just take an existing client

Cons:

  1. See Pro for 2.
  2. See Pro for 1.

Since I am not a software developer, I thought I’ll ask around here for some thoughts, opinions and tips :)

Talking about taking/forking/using ether an existing client or server app, I would only considers a popular/proven and not some edge products. Thanks, if you made it all the way down here :)

  • litchralee@sh.itjust.worksEnglish
    0·
    12 hours ago

    As the other commenters have noted, what sort of adversary are you trying to protect against? There is no such thing as “security for its own sake” but rather security measures like E2EE are to protect against specific types of attacks. Do you believe a ticketing system is vulnerable to attacks that E2EE would mitigate?

    As an aside, please do not consider PGP to be a pinnacle of signing or encryption. I’ve opined in another project before about why Late 20th Century PGP isn’t that good in the 21st Century.

    But even with a modern replacement for PGP, how would E2EE even work for a multi-user ticketing system? If everyone on the support side has the same key, then key management becomes (as usual) the most crucial part of the operation, and remains an unsolved problem at scale. This is no different than physical key management, when every member of the custodial team needs to have the “super key” that opens every door of a university campus.