Having the secret key known to Jenkins makes me a little uncomfortable.
Instead I see two ways around it.

1. Don't require the privateKey in the global configuration. If the privateKey is null, then assume it is imported already (from the command line by someone logged in as the jenkins user).
2. Declare the privateKey to be hudson.util.Secret (as you do with the passphrase), and do a getPlainText() on it before importing it.

This is a feature request to make this plugin compatible with pipeline.

https://jenkins.io/doc/developer/plugin-development/pipeline-integration/

Is this project still being maintained at all? We have been using it, but are reconsidering since there hasn't been any activity in nearly 3 years.

If there is a space in the project or job name, such as "package building", then the rpm path includes a space and the rpmsign command return an error complaining it can't find "building/myrpm-1.0-1.el6.noarch.rpm" when it should be signing "/var/lib/jenkins/workspace/MyProject/package building/myrpm-1.0-1.el6.noarch.rpm."

The feature was added in commit: rpm-software-management/rpm@932f14f

In all modern systems with rpm >= 4.14.0-rc1, you should be able to rely on _gpg_sign_cmd_extra_args as upstream feature.

If your __gpg_sign_cmd is defined as:

#==============================================================================
# ---- GPG/PGP/PGP5 signature macros.
#       Macro(s) to hold the arguments passed to GPG/PGP for package
#       signing and verification.
#

%__gpg_sign_cmd                 %{__gpg} \
        gpg --no-verbose --no-armor \
        %{?_gpg_digest_algo:--digest-algo %{_gpg_digest_algo}} \
        --no-secmem-warning \
        %{?_gpg_sign_cmd_extra_args:%{_gpg_sign_cmd_extra_args}} \
        -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}

Then _gpg_sign_cmd_extra_args is exactly the feature you need. You can do this just by adding this to .rpmmacros:

%_gpg_sign_cmd_extra_args --pinentry-mode loopback

And now you can be sure you are not going to break __gpg_sign_cmd in the future.

On large packages, the plugin will silently fail as the expect timeout of 10 seconds is met:

[RpmSignPlugin] - Running rpm --define "_gpg_name *****************" --verbose --addsign /home/jenkinsbuild/workspace/*********/***.rpm
[****] $ expect -
spawn rpm --define _gpg_name ********* --verbose --addsign /home/jenkinsbuild/workspace/*********/***.rpm
Enter pass phrase: 
Pass phrase is good.
/home/jenkinsbuild/workspace/*********/***.rpm:
[RpmSignPlugin] - Finished signing RPMs ...
[RhnPush] - Starting publishing RPMs ...
[****] $ rhnpush --server=*** -u *** -p *** -c *** /home/jenkinsbuild/workspace/*********/***.rpm
ERROR: /home/jenkinsbuild/workspace/*********/***.rpm: unsigned rpm (use --nosig to force)
[RhnPush] - Failed publishing RPMs ...
Build step '[RhnPush] - Pushes RPMs to Spacewalk or RHN server' marked build as failure

Testing outside the Jenkins environment using a similar expect approach yields the same result. Only after adding a 'set timeout N' with any suitable value before the spawn would fix this. In my case the signing process took around 18 seconds. It would worth adding an option for this in the plugin configuration :). Thank you

Please put into documentation that key name in jenkins config must be same as key name