i have cloned SoapUI form GitHub to test my plugin against the latest development branch. To my surpirse the plugin wasn't loaded anymore. An error message was shown in the log that the plugin was not loaded because it contains unsigned classes.
After digging into the code i found a ProductBodyguard.java which was newly introduced in September '15. This class is responsible for checking the signature of loaded plugin classes to a smartbear public certificate.
My questions so far:
Who is responsible for signing plugin jars from the community?
How does this align to the idea of open source?
Any discussion is very welcome.
thanks for that link. But it did not help me much.
I already have a developed a plugin. You can find it on GitHub (https://github.com/hschott/ready-websocket-plugin) and it is listed on the page you linked to.
I have developed against SoapUI OS 5.2.0 with no problems. When running the same plugin inside SoapUI OS 5.2.1 i'm getting an error message, that the plugin could not be loaded, because it is not signed by Smartbear.
09:01:50,412 ERROR [SoapUI] An error occurred [The plugin '/Users/hos/.soapuios/plugins/ready-websocket-plugin.jar' has unsigned class files.], see error log for details
Please see also this Pull request on GitHub https://github.com/SmartBear/soapui/pull/201 .
Any ideas about that.
As far as I know some changes with the plugin manager were implemented in SoapUI 5.2.1. Since that, only SmartBear-made plugins can work with the new manager.
I can suggest the following options for you:
i'm sorry but i can not accept that.
This change has a very deep impact on the behavoir of SoapUI OS.
It was done on a patch level version change 5.2.0 > 5.2.1.
It is nowhere documented.
There is no hint in the release notes.
It does not correspond to the idea of community driven open source.
Please revert this change in the next release.
I too echo Holger's concerns about these new constraints regarding plugin development for open source SoapUI.
Are you able to say what the motivation is for these changes? Is the extra security / controls in response to some kind of risk of abuse of free plugins?
I had initially imagined that the motivation for porting aspects of the SoapUI NG plugin framework features (minus the plugin manager) to the open source version was in an attempt to unify plugin development across the commercial and open source versions of SoapUI, which would be nice idea for Smartbear, and might encorage more people to write plugins.
Also, given that unsigned plugins now don't work on the O/S version, what is the suggested development approach for open source only users? In other words, without modifying SoapUI to remove the security constraint, how should people test the plugins they create?
I for one, often consider writing plugins only with a view to using/sharing them for O/S SoapUI use, so would appreciate any official views on the matter that you may be able to give.
Thanks for any info you can give,
This change definitely is not welcomed by Open Source community, I believe.
I do not see an issue for the plugin developers to submitting plugin to Smartbear, in fact, users might love it if some piece of software written by them goes to a well named software.
But, before that, plugin needs to verified for themselves wether the plugin, written by them, is working as per the expectations or not. As per the changes mentioned, it appears that it may not possible to test for the plugin author until it goes thru productizing it and new release is done.
Another, probablity could be Smartbear has right to productize the idea or not depending on the value that it brings to table. However, the original author might need it for his/her project to test or automate.
Do we continue to have SoapUI OS releases? just curious after looking at #2.
I believe, what could be more welcomed by Open Source community would be :
Thanks for sharing your opinion! I cannot change anything in this situation 😞
However, I've passed this information to the SoapUI Product Owner so that he would be aware about this.
for all of you running into the same problem i recommend to have a look at https://github.com/hschott/soapui-pluginloader-jailbreak . This little peace of code will help you to bypass the ProductBodyguard, while testing your plugin.