Do i have to sign my plugin from SoapUI 5.2.1 on?

[hschott]

Hi,

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.

Regards,

Holger

[nmrao]

Did you happed to see this link
http://community.smartbear.com/t5/SmartBear-Developer-Network/ct-p/SmartBear_Developer_Network

[hschott]

Hi,

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.

Regards,

Holger

[TanyaYatskovska]

Hi Hschott,

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:

1. You can send your plugin at soapuiplugins@smartbear.com. Our team will review it and add to the product.
2. You can consider moving to SoapUI NG - user-made plugins are allowed here. SoapUI NG is the newest SoapUI version and it is included into Ready! API.

[hschott]

Hi Tanya,

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.

Regards,

Holger

[rupert_anderson]

Hi Tanya,

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,

Rupert

[nmrao]

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 :

1. If there is no certain feature, that is fine.
2. Continue with existing features.
3. If certain feature is going to be deprecated, have it in release notes. That would set the user expectations right or will not be a surprise.
4. Just specific to this case, provide a utility that can sign the user plugins as desired by new plugin manager / loader if the new stuff is manadatory.
5. New ideas can come from any one who might be technical/non-technical, Open Source/Pro users. Depending on the value that it fetches, the idea may productized or may not be at times. If some thing can be extendable, that would be good for both Pro and OS softwares.
6. I do understand that plugins play an important role. Thank you for Smartbear team for productizing this feature to the API tools which makes easy to develop new plugins. Again if some plugin is more critical to certain users may bring zero value to certain users. What I wanted to say here is when users have flexibility they continue to use software (irrespective of paid or unpaid software) rather than looking for alternatives.

[TanyaYatskovska]

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.  

[hschott]

Hi,

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.

Regards,

Holger

[hschott]

Hi Tanya,

i would very apreciate and welcome to read a post by @MFagerlind, @OLensmar or @LBrandon about this topic and the roadmap of SoapUI OS.

Regards,

Holger