Plugin Testing

The requirements imposed on the plugin installation process create some complications when it comes to testing snapshots or beta versions of plugins prior to an official release. Most of these limitations are pretty simple to work around, but there are some limitations that have yet to be addressed.

Fundamentally:

• Signatures are mandatory, there is no means of bypassing them.

• Installing or upgrading plugins by plugin ID is not possible because the property file posted online that makes it possible does not know about unofficial versions of the plugins or the IdP software and will claim they are not supported or available.

• There is a limitation in that while plugins can be installed from a local file archive, they can’t be upgraded that way yet.

As a result, the following workarounds are required.

New Installs

To install plugins from scratch is fairly simple.

1. Download the desired “prerelease” plugin via our project status table at https://shibboleth.net/cgi-bin/projstatus.cgi. The page allows you to check the current status of a plugin, identify the SNAPSHOT version available for download, and provides a direct link to the download location. (Of course you could also build from source yourself.)

2. Download the corresponding .asc signature file along with it if available, or you would need to generate a local GPG key and sign them yourself.

3. Place the public signing key into a local file (or download it if one is provided).

   1. If you download the artifact directly from Nexus, it will be signed by Jenkins. To use the Jenkins key as the truststore, download it from https://shibboleth.net/downloads/SHIBBOLETH_SNAPSHOT_PGP_KEYS.

4. Install the plugin directly from the local file using a command like the following (the Windows equivalent is roughly the same obviously):

The noCheck parameter bypasses the property file check that enforces supported versions. The truststore must point to the local copy of the signing public key.

Upgrades

Because of the noted limitation above that plugins cannot be forcibly installed via distribution file yet, unfortunately the only way to test an unreleased version at this stage is to just remove/uninstall the original version and then do a forced install as above. The removal will leave behind saved copies of configuration files in some cases, and you can then copy those “.idpsave” copies back over the “default” files created by the new install process once it completes. This is generally good enough to ensure a valid test, at least until we add the missing support for upgrading directly.