Thanks for that explanation of what’s going on behind the scenes. I will
try to test the inbound email shortly.
In any case, it sounds like I’ll have to think up some other ideas. Our
users occasionally need to communicate (via RT) with people who aren’t
themselves users of RT, and who didn’t initiate the communication with an
inbound email, so I don’t think we would be able to rely 100% on the
inbound fetching of keys.
On Tue, Jul 30, 2013 at 02:19:29PM -0400, Christopher Costa wrote:
It looks as if testing inbound email to RT might not be a simple
chore in my environment so
for now I’m going to focus on outbound email. I do have debug logging
enabled. Is there is
someplace else worth looking? Am I misunderstanding how auto key
retrieval is supposed to work
with outbound mail?
RT calls gpg --list-public-keys bob@example.com which I don’t think
fetches automatically. I think that only happens during the encrypt.
Most of the time this is a non-issue because the verification when
mail enters the system does fetch.
In order to work around this, RT would need to add a bunch of fetch
keys logic, which unfortunately was explicitly not-in-scope when this
was implemented for RT 3.8.0.
Also, testing inbound email should be pretty trivial, even if you
can’t glue all the parts together.
Take a signed email in a text file and run:
/opt/rt4/bin/rt-mailgate --queue General --url htt://foo.com --action
correspond < email
-kevin
On Tue, Jul 30, 2013 at 12:18 PM, Christopher Costa <[1] christopher.costa@gmail.com> wrote:
Hi Kevin,
Thus far my focus has been on getting outgoing email to work
(that’s our primary need). I
will make every effort to test inbound email ASAP.
On Tue, Jul 30, 2013 at 12:09 PM, Kevin Falcone <[2] falcone@bestpractical.com> wrote:
On Tue, Jul 30, 2013 at 11:18:38AM -0400, Christopher Costa wrote:
> I have been able to get GPG integrated with RT using manually
installed public keys, but
I'm
> now trying to get auto key retrieval to work. The RT
documentation suggests (to me,
anyway)
> that this is possible. I haven't had any luck getting it
working, and I’m curious if any
other
> users have, and would have any tips. I've configured RT this
way in RT_SiteConfig:
You say you've tested without outgoing emails, have you tested
with an
incoming mail from an unknown user?
Also, ensure that your logging is set to debug, not just error.
-kevin
> Set(%GnuPG,
> Enable => 1,
> OutgoingMessagesFormat => "RFC", # Inline
> AllowEncryptDataInDB => 0,
> RejectOnMissingPrivateKey => 1,
> RejectOnBadData => 1,
> );
>
> Set(%GnuPGOptions,
> homedir => q{var/data/gpg},
> keyserver => 'xxxx://xxx.xxx.xxx.xxx',
> 'always-trust' => undef,
> 'auto-key-locate' => 'keyserver',
> 'keyserver-options' => 'auto-key-retrieve',
> );
>
> However, when I attempt to send an email to somebody who
doesn’t already have a key on
the
> keyring, I get this error in the UI:
>
> User XXXXXXXXXX has a problem. There is no key suitable for
encryption.
> Select a key you want to use for encryption: No usable keys.
>
> and in the rt.log I see this:
>
> [Tue Jul 30 13:24:51 2013] [error]: gpg: error reading key: No
public key
> (/opt/rtdev/sbin/../lib/RT/Crypt/GnuPG.pm:2163)
> [Tue Jul 30 13:24:51 2013] [error]: gpg: error reading key: No
public key
> (/opt/rtdev/sbin/../lib/RT/Crypt/GnuPG.pm:2163)
> [Tue Jul 30 13:24:51 2013] [error]: gpg: error reading key: No
public key
> (/opt/rtdev/sbin/../lib/RT/Crypt/GnuPG.pm:2163)
>
> It *appears* that RT is checking the keyring, and erroring out
if it doesn’t find a key,
which
> is not what I expected to happened (I was expecting the key
would be retrieved
automatically
> at the time of encryption).
> I have executed gpg from the command line with these options,
and I can retrieve a user
key
> automatically and encrypt a file. So I am pretty sure the
problem isn’t with the
keyserver, or
> the options themselves. I'm holding out hope that I'm simply
doing something wrong
within RT,
> and that there is some other setting I've overlooked.
>
> Thanks!
> Chris
References
Visible links
- mailto:christopher.costa@gmail.com
- mailto:falcone@bestpractical.com