| 37 | | ''Is it right that different users will have different keys? If so we can add configuration to the user's preference page. We could have a big textbox for GPG key and if they have one entered, then use encryption. |
| | 33 | ==== !AnnouncerEmailEncryption ==== |
| | 34 | Now let's look at how OpenPGP could help with Trac and especially with announcements. |
| | 35 | |
| | 36 | Imagine, you're using trac in a corporate environment, typically allowing external access to trac, repositories etc. only after authorization or not at all. |
| | 37 | However you may wish to keep business partners, support customers or even co-workers outside the tightly controlled corporate network informed about certain or all developments. Encrypting mail for external recipients will help to deal with issues as discrete as you like while still using announcements for changes in trac. |
| | 38 | |
| | 39 | To get !AnnouncerEmailEncryption up and working you'll have to do take the following steps: |
| | 40 | 1. install GnuPG on the same host along with Trac[[BR]] |
| | 41 | For Debian GNU/Linux a simple {{{apt-get install gnupg}}} will do. |
| | 42 | 2. install python-gnupg |
| | 43 | Currently there is no Debian package available. Install from source of [http://code.google.com/p/python-gnupg/downloads/list project site] is preferred. |
| | 44 | 3. configure !AnnouncerEmailEncryption in the ![announcer] section of trac.ini for the given trac environment |
| | 45 | * gnupg_dir = <path_to_dir>, will default to something like {{{<tracenv>/gnupg}}}[[BR]] |
| | 46 | If not existent, this directory would be created and populated with necessary (initially empty) files on next trac start with !AnnouncerEmailEncryption enabled. |
| | 47 | * msg_encryption = False|True, default to "False" |
| | 48 | Pretty self-explaining. External would opt for splitting recipients according to following rules into group require_encryption_group and allow_verbatim_msg_group and sending an local, verbatim as well as an encrypted version in parallel, if both recipient lists are not empty. |
| | 49 | * external recipient_rule = (list of e-mail addresses or regex describing range of e-mail addresses) |
| | 50 | 4. import pubkeys and associate with users |
| | 51 | * admin: |
| | 52 | * (mass-)upload from local pubkey(ring) files |
| | 53 | * upload from local or public keyserver |
| | 54 | * associate pubkey from previous upload with users |
| | 55 | User administration should allow for key import and association to users on behalf of every registered user. |
| | 56 | * user: |
| | 57 | * upload like admin, but associate only to himself/herself |
| | 58 | * select pubkey from previous upload (self or admin) |
| | 59 | Users may wish to add an OpenPGP key to their configuration. |
| | 60 | For simplicity I'd make existence of a pubkey equivalent to an "always encrypt msg for me with this key" option. |
| | 61 | For convenience it might still be possible to temporarily disable a key and re-enable it later without deletion and re-import as this is directly supported by GnuPG. |
| | 62 | 5. add an automatic signing key for the given trac environment (optional) |
| | 63 | * upload from local pubkey(ring) file or create it on-demand |
| | 64 | * use secret key, if only one is available, else provide a drop-down or similar for selection |
| | 65 | For convenience it should be possible to temporarily disable a key and re-enable it later without deleting it. |
| | 66 | |
| | 67 | Beware, that this is by now no code but pure concept and subject to change a lot, before public release of the code. As with current code for AnnouncerPlugin there'll be DEBUG logging embed into all operations mentioned above. |
| | 68 | |
| | 69 | ==== Q&A ==== |
| | 70 | ?: ''Is it right that different users will have different keys? If so we can add configuration to the user's preference page. We could have a big textbox for GPG key and if they have one entered, then use encryption. |
| | 71 | A: Yes, different users will (typically) have different keys. It might be desirable even to support multiple keys per user. Only in rare cases one key would be associated with different users/e-mail addresses, even if this might be technically perfectly valid and useful. But it indicates violation of the de-facto standard one-owner-per-key that abhor kind of group keys. |
