KarelHusa's avatar
KarelHusa
Champion Level 3
8 years ago
Status:
Implemented

Configuration to allow loading unsigned plugins

Configuration to allow loading unsigned plugins

 

Description

Currently SoapUI-5.3.0 allows to load only the plugins which are signed by Smartbear, for security reasons. This precaution prevents to develop, test and use the plugins which are not signed by Smartbear. Asking Smartbear to sign every JAR we need to test is not feasible. The enforcement of signing the plugins is contrary to open source principles.

 

Proposal

Introduce a configuration item in SoapUI properties, which allows loading unsigned plugins. The item can be set to false by default, but the user will be able to allow it at his own risk. There can be a short notice about potential risks.

 

Benefits

The implementation would allow more freedom and flexibility to both SoapUI contributors and users and encourage people to develop new/custom plugins.

 

 

3 Comments

Sort By
  • rupert_anderson's avatar
    rupert_anderson
    Valued Contributor
    8 years ago

    Hi Karel,

     

    This is a topic that I strongly agree with, has been discussed previously, as you may be aware:

     

    https://community.smartbear.com/t5/SoapUI-Open-Source/Do-i-have-to-sign-my-plugin-from-SoapUI-5-2-1-on/m-p/108694/highlight/true#M18708

     

    When considering developing some functionality as a plugin, namely:

     

    http://rupertanderson.com/blog/replace-teststep-request-soapui-plugin/ (solution to another feature request)

     

    I considered packaging the code as a plugin (previous way i.e. unsigned) and adding code to to overcome the check (similarly to https://github.com/hschott/soapui-pluginloader-jailbreak), but this seemed a passively confrontational way to go about things and working together is almost always a much better option. So, because I just wanted to trial the solution, I opted to package my functionality the old way, as an extension, but this is less neat than packaging the functionality as a single file. Also, in terms of this functionality, I've no idea at this stage whether it is actually sufficiently good and useful to warrant actually getting it endorsed and signed - I just wanted to get it out there, in an 'open source' way and obtain the feedback I need to improve it.

     

    I think the idea of optional config to disable the check is a good one, as it maintains the defensive position. An alternative might be just show a warning / disclaimer for unsigned plugins (could be just a log message, or popup, that can be optionally ignored).

     

    Basically, as an aspiring 'open source' plugin developer I would like a life cycle like:

     

    1) Be able to release a prototype plugin (unsigned) - gain feedback, improve or abandon.

    2) If successful, optionally approach smartbear to get the plugin signed.

     

    Again, if its just a question of finding someone to do the coding, I'd be more than happy to help on either of the above options. However, like your other feature request (re the error that is thrown loading the packed plugins), I think the first move probably needs to come from smartbear / product team to endorse any approach in keeping with any SoapUI O/S plugin strategy they might have.

     

    Anyway, nice feature request! :-) 

     

    Thanks,

    Rupert