Redmine

This patch adds a new custom field format, "Encrypted text", for issue custom fields (based on r25288).

Users sometimes need to keep credentials or API keys in issues, but these values are currently stored in plain text in custom_values and journal_details. When the production database is copied to a staging environment, a dump is handed to a third party for troubleshooting, or a database administrator looks at the tables directly, these values can be read as they are. Disk or database-level encryption does not help in these cases, because the values are returned in plain text once they are read from the database.

With this patch, values are encrypted by Redmine before being stored in the database. They stay encrypted in database copies and dumps, and cannot be read without the key (database_cipher_key).

Overview of the behavior:

• Values are encrypted with the existing Redmine::Ciphering (database_cipher_key) when saved, and decrypted when read. No new setting is added.
• Within the application, the field behaves like a regular single-line text field. Users who can see the field (role-based visibility) see the plain value in the UI, the REST API, email notifications, etc.
• The edit form uses a password field, in the same way as repository and LDAP passwords.
• Values are not stored in journal_details. The history only shows that the field was updated.
• Filtering, searching, sorting, grouping, bulk editing, default value and link URL are not available.
• rake db:encrypt and rake db:decrypt also process these values.
• When the key is not set, fields with this format cannot be created, and existing ones are treated as not visible and not editable (the stored ciphertexts are kept). Administration > Information shows whether the key is configured.

This patch only protects the values stored in the database. It assumes that the key is managed separately from the database, and it is not meant to hide values from users. Values submitted through forms or the API that appear in the request log are out of scope of this patch.

I have also considered implementing this as an option (checkbox) of the "Text" format. If that approach is preferred, I will rework the patch that way.