I’m playing around with GPG integration in RT and once grasped the
concept of keys and configuring server side and client side it seems to
work beautifully. Reading the docs I came across the following and don’t
understand what its meaning/use case is.
AllowEncryptDataInDB: allows encrypted data in the database.
While having this set or unset I don’t see any difference in the
contents of the attachments table contents.
RT-4.0.13 without any customizations. (upgrade is in the pipeline), user
has more than sufficient privs.
Can someone explain what its use case is and how to use it?
AllowEncryptDataInDB: allows encrypted data in the database.
While having this set or unset I don’t see any difference in the
contents of the attachments table contents.
It shows an Encrypt/Decrypt link on Transactions in a ticket history.
You can then choose to encrypt/decrypt a given transaction so it’s
encrypted in the DB.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On 17-6-2014 20:55, Kevin Falcone wrote:
On Sat, Jun 14, 2014 at 05:59:44PM +0200, Joop wrote:
AllowEncryptDataInDB: allows encrypted data in the database.
While having this set or unset I don’t see any difference in the
contents of the attachments table contents.
It shows an Encrypt/Decrypt link on Transactions in a ticket history.
You can then choose to encrypt/decrypt a given transaction so it’s
encrypted in the DB.
Thanks Kevin for your answer. I didn’t link this pref with the
Decrypt/Encrypt links in the transactions.
Follow up question on this is: It is the admins responsibility to use
the correct RT permissions to make sure not everyone can see the content
of all tickets.
My first and colleagues too reaction was that if someone doesn’t have a
pgp key that they shouldn’t be able to see the ticket but that is not
true. Ticket content is visible because the queue private key is
available isn’t it?
So correct workflow would be: Create Queue_with_sensitive_data, setup
pgp on it, create group and assign RT privs to it, put the correct
people in the group.
Joop
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
Thanks Kevin for your answer. I didn’t link this pref with the
Decrypt/Encrypt links in the transactions.
Doc patches welcome, I had to grep to convince myself it was the only
thing.
Follow up question on this is: It is the admins responsibility to use
the correct RT permissions to make sure not everyone can see the content
of all tickets.
Correct. You do also need ModifyTicket, so just ShowTicket isn’t
enough to decrypt the message and see it.
My first and colleagues too reaction was that if someone doesn’t have a
pgp key that they shouldn’t be able to see the ticket but that is not
true. Ticket content is visible because the queue private key is
available isn’t it?
So correct workflow would be: Create Queue_with_sensitive_data, setup
pgp on it, create group and assign RT privs to it, put the correct
people in the group.
Something like that. This option is really there because people
didn’t trust the DBA or wanted encrypted data in the backups. But in
reality, if someone has root access to your webserver, they can get at
your keyring, etc etc.
Encrypting to a single user key isn’t currently supported by this,
might be a good idea, but could end up going horribly wrong if you
think through a user termination.