[rt-users] GnuPG key management issues

[Alex Vandiver]

On Thu, Oct 08, 2015 at 08:40:37AM +0200, Christopher Kunz wrote:
> we are using the RT::Crypt::GnuPG module and have run into an issue that
> I'm afraid we cannot solve.
> [snip]
> This is where the problems start. With our current setup (and a local
> keyring on the RT server), RT will try handling the .asc attachment as
> encrypted data (which it isn't), fail and not handle the rest of the
> ticket.

I believe the 4.2/skip-asc-keys branch[1] addresses this particular
issue, of interpreting .asc as encrypted data.  I'm sure that BPS
would appreciate the feedback if it resolves the issue for you.

> We are using RT 4.2.8. Is there any configuration setting that I might
> have missed, or any other possibility to get RT to automatically import
> keys that come into the system as a .asc attachment? I am aware of the
> security implications of this (and, in fact, have set the trust settings
> to "always", as authentication of user requests is always performed
> separately).

The security implications of such a flag almost certainly preclude its
inclusion in core RT -- though you understand the security
implications, many sites might not, and might enable it regardless of
any warnings placed on it.  Operating in such configurations is far
worse than operating without GPG at all.

If you wish to implement this yourself, there are a couple options for
where to implement the behavior.  The first two of them will require
that the web user have write access to the keyring.

  1. Implement it as a mail plugin, run before RT::Crypt::GnuPG.  This
     will allow it to import the key before the decryption happens.
     Mail plugins in 4.2 are cumbersome, but an ApplyBeforeDecode
     plugin that is in @MailPlugins before Auth::Crypt should work fine.

     I would suggest using RT::Extension::FutureMailgate[2] backport
     of the 4.4/mailgate-refactor branch[3] to make writing the mail
     plugin entirely more friendly, but I just checked, and it looks
     like that backport doesn't include the Crypt changes from the
     branch[3], so running that may be unhelpful.

  2. Write a scrip to parse out the keys after the mail comes in.
     This means that if the original mail is signed by the key it
     includes, the key will be added after it has been examined, so it
     will be marked as unverified.

  3. Pre-process the keys in the mail gateway, or before.  If the mail
     has a standard format, you can potentially do all of the work by
     having procmail or similar match the message and pipe it to a
     custom program that extracts and adds the key.  This removes RT
     from the loop entirely.

If this is central to your workflow, you may wish to consider
contacting sales at bestpractical.com to see if they can help you
implement one of the above solutions.
 - Alex

[1] https://github.com/bestpractical/rt/compare/4.2-trunk...4.2/skip-asc-keys
[2] https://github.com/bestpractical/rt-extension-futuremailgate
[3] https://github.com/bestpractical/rt/compare/master...4.4/gateway-refactor