Problems using gnupg keys

Hi,
after several tests, reads and searches, I realized I was stuck with an RT error, maybe simple for RT experts, so I decided to question this forum trying to find some help.

I’m testing RT and installed version 4.4.4 on CentOs. After installed all dependencies and ran initial setup, it is working with Apache as webserver. I created a gnupg key pair for using with it and this key pair works fine on command line, for example, in signing files.

After several attempts to understand how it works in RT, I understand that independently my conf, gpg always use gpg-agent and pinentry-curses. That was my first problem when trying to sing emails, because I was getting the error “signing failed: Inappropriate ioctl for device”. After I realized why and test several confs, I was able to correct this error and moved on to another one, “gpg: signing failed: Invalid length”. I got this error when running Apache with passphrase configured or when running /opt/rt4/sbin/rt-server and insert passphrase manually when pinentry-curses asks for it.

Trying to eliminate variables, I removed the key’s passphrase, but the error remains, and I think it is not related to passphrase.

The automatic download of pub keys, when receiving emails, check them and identify the key to use for the queue email address are working fine.

After activating debugs, seams that the error comes from the agent, and I don’t know why. These are the only errors I got from several tests I made:
RT[11262]: [11262] [GNUPG:] KEY_CONSIDERED 3XXXXXXXXXXXXXF1 0
[GNUPG:] KEY_CONSIDERED 3XXXXXXXXXXXXF1 2
[GNUPG:] BEGIN_SIGNING H2
[GNUPG:] FAILURE sign 67109003 (/opt/rt4/sbin/…/lib/RT/Crypt/GnuPG.pm:407)
RT[11262]: [11262] gpg: using “xxxx@xxxxx” as default secret key for signing
gpg: signing failed: Invalid length
gpg: signing failed: Invalid length

With more debug:
gpg: DBG: setting Signer’s UID to ‘xxxx@xxxxx’
gpg: DBG: get_keygrip for public key
gpg: DBG: keygrip= BXXXXXXXXXXXXXXXXXF
gpg: DBG: chan_4 -> RESET
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> SIGKEY BXXXXXXXXXXXXXXXXXXXXXF
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22XXX+XX+XXX+XXX+XXXX@xXXXXX%22%0A3072-bit+DSA+key,+ID+XXXXX1,%0Acreated+2020-03-19.%0A
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> SETHASH 2 3XXXXXXXXXXXXXXXXXXXE
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> PKSIGN
gpg: DBG: chan_4 <- ERR 67109003 Invalid length
gpg: signing failed: Invalid length

Versions:
CentOs 8.1.1911
Apache/2.4.37
gpg (GnuPG) 2.2.9
libgcrypt 1.8.3
GnuPG::Interface 0.52

My gnupg conf:

PGP Settings

Set(%GnuPG,
Enable => 1,
GnuPG => ‘gpg’,
Passphrase => undef,
OutgoingMessagesFormat => “RFC”, # Inline
);

Set(%GnuPGOptions,
homedir => q{var/data/gpg},
#‘debug-level’ => ‘guru’,
‘no-permission-warning’ => undef,
‘trust-model’ => ‘always’,
‘auto-key-locate’ => ‘keyserver’,
‘auto-key-retrieve’ => undef,
keyserver => ‘hkp://keyserver.ubuntu.com’,
‘keyserver-options’ => ‘http-proxy=http://192.168.1.1:3128’,
);

Best regards,

I believe right now only GPG 1 is supported

As I recall this is because GPG2 does not allow a pass phrase to be stored in a file

After you mentioned it I noticed that nowadays systems change gpg and gpg2 for the same version (a few years ago we had the two versions coexisting in systems :)) so I compile the old version 1 of gpg and now it works.

In my opinion, if gpg version 2 is not supported by RT, such requisite should figure on documentation, if it is, my fault but I didn’t find it, sorry, such info will saves a lot of time for people that are starting with RT :wink:

Thanks for the help, regards.

1 Like

RT works fine with gpg2. We are using a password though, passed via

Set( %GnuPGOptions,
             passphrase => 'password',
);

just like other options.

Maybe is the versions that came with CentOS 8, II’m not sure, I tried that, and also inserted the passphrase manually in pinentry when asked for it an also I removed the passphrase but I got always the same error.

With gpg1 it seams to working fine. Only when I received an encrypted message it decrypts it but I can’t read the message on the interface, I must download the decrypted MIME attach and read it and parse it to get the attachments that are base64 encoded, as expected. Maybe I’m forgetting something or is this the expected behavior?

The rest it seams to working as expected.

Best regards,