Centralrized Data options

The vulnerability data makes up most of the plugin’s file size. It is currently about 84 percent of the size and the percentage should increase as more vulnerabilities are added (it was about 70 percent of the size six months ago when we responded to a similar suggestion). So at this point there doesn’t seem to be much advantage to creating a separate update mechanism just for the vulnerability data instead of updating it along with the rest of the plugin through the normal WordPress update mechanism.

Okay no problem. The reason I was suggesting it was to make the data in a PHP-independent format so it could be re-used in other contexts.

I’ll work something else out sure. Thanks.

Hi WhiteFirDesign,

Firstly, thanks for this very useful plugin! I also use your No Longer in Directory plugin ?? They both contribute a lot to helping me feel confident in the plugins I’m using.

I’m just wondering, after reading the review Plugin shows up as Malware when screening site from a week ago and the support thread Great idea, but bad implementation from two months ago, why you would reject Paul G.’s idea? It seems it might at least go part way in solving the issues which seem to exist with this plugin…

Thanks in advance for the explanation, and cheers!

I have gone ahead and created a YAML based representation of the vulnerability data.

You can use it as you need. I’ll do my best to keep it up-to-date as this plugin grows.

https://github.com/FernleafSystems/wp-plugin-vulnerabilities

Thanks!
Paul.

WhiteFirDesign, it seems like you’ve missed the point of both of the suggestions for extracting the data. In each case, the suggestions were to make the data more accessible – in this case, to another useful plugin. It wasn’t really about making it easier to update the Plugin Vulnerabilites plugin ??

@paul G.

We’d appreciate it if you not lift our data for your own plugin like this.

@tdmalone

Did you consider that we don’t want people taking our data and using it in their plugins? This plugin is the small public face of larger project that involves a lot of behind the scenes work to get plugin vulnerabilities fixed (or at least removed from the Plugin Directory until they are fixed). If our data is available in other plugins that reduces the already limited value we get back through this plugin for all that behind scenes work we do and it makes it harder for us to continue justify the larger project going forward.

@julie @Niackery

Neither of those mentions things that we see as a problem with the plugin.

For the first, the issue is poor malware scanner at that web host, which unfortunately isn’t an uncommon situation. The files being flagged simply contain the data for the plugin, like this:

‘$plugin_vulnerabilities[“calculated-fields-form”] = array(
“1” => array(
“FirstVersion” => “1.0.1”,
“LastVersion” => “1.0.10”,
“TypeOfVulnerability” => “cross-site request forgery (CSRF)/SQL injection”,
“URL” => “https://packetstormsecurity.com/files/130603/WordPress-Calculated-Fields-Form-1.0.10-SQL-Injection.html”
),
);’

One of the things they appear to be flagging is the inclusion of the now former domain name of a vulnerability database website. So as long as we store the vulnerability data, even if just in a cache file, it could be flagged and therefore changing the update mechanism isn’t the solution for this issue.

For the second, the issue raised it seems to be that if you are not keeping your plugins up to date then our plugin “won’t know about new vulnerabilities and can’t inform you about them”. That is true, but if you are not keeping your plugins up to date you are going to have a bigger problem than not having the latest data for our plugin.

Our plugin can only possibly warn about publicly disclosed vulnerabilities, so if a developer fixes a vulnerability and no one discloses it wouldn’t be possible for our plugin to warn about it. When did some research on this a while ago we found that for about 20 percent of vulnerabilities in our sample set the developer didn’t mention that vulnerability was fixed their changelog entry for the version that included the fix for it.

We also try to make sure the developer has been privately notified about an unfixed vulnerability before we add it to our plugin, so the developer has a chance to fix it before we provide more attention to the vulnerability. We also do that because it is lot more useful for the plugin to be fixed than for us to warn people about an unfixed vulnerability and for them to have to decide how to handle it, so our plugin is really designed to be used along side of keeping plugins up to date and making it work without keeping plugins up to date would likely be counterproductive from a security perspective.

@julie @Niackery

Neither of those mentions things that we see as a problem with the plugin.

For the first, the issue is poor malware scanner at that web host, which unfortunately isn’t an uncommon situation. The files being flagged simply contain the data for the plugin, like this:

$plugin_vulnerabilities[“calculated-fields-form”] = array(
“1” => array(
“FirstVersion” => “1.0.1”,
“LastVersion” => “1.0.10”,
“TypeOfVulnerability” => “cross-site request forgery (CSRF)/SQL injection”,
“URL” => “https://packetstormsecurity.com/files/130603/WordPress-Calculated-Fields-Form-1.0.10-SQL-Injection.html”
),
);

One of the things they appear to be flagging is the inclusion of the now former domain name of a vulnerability database website. So as long as we store the vulnerability data, even if just in a cache file, it could be flagged and therefore changing the update mechanism isn’t the solution for this issue.

For the second, the issue raised it seems to be that if you are not keeping your plugins up to date then our plugin “won’t know about new vulnerabilities and can’t inform you about them”. That is true, but if you are not keeping your plugins up to date you are going to have a bigger problem than not having the latest data for our plugin.

Our plugin can only possibly warn about publicly disclosed vulnerabilities, so if a developer fixes a vulnerability and no one discloses it wouldn’t be possible for our plugin to warn about it. When did some research on this a while ago we found that for about 20 percent of vulnerabilities in our sample set the developer didn’t mention that vulnerability was fixed their changelog entry for the version that included the fix for it.

We also try to make sure the developer has been privately notified about an unfixed vulnerability before we add it to our plugin, so the developer has a chance to fix it before we provide more attention to the vulnerability. We also do that because it is lot more useful for the plugin to be fixed than for us to warn people about an unfixed vulnerability and for them to have to decide how to handle it, so our plugin is really designed to be used along side of keeping plugins up to date and making it work without keeping plugins up to date would likely be counterproductive from a security perspective.

Hi WhiteFirDesign, in regards to you not wanting the data used… isn’t that the spirit of open source development?

You mentioned it makes it harder for to justify the work you put into the plugin… why not collaborate with others and end up with an even better plugin – and WordPress plugin security – for everybody? Putting a lot of work into plugin security so you can take the glory doesn’t really make a lot of sense; if your true desire is better security for WordPress then it would follow that collaborating with other security plugins – and other interested developers – would actually further your cause, not restrict it.

well,

It is easier to talk about open source, but it is hard to create a business model with it. I understand that. But if the problem is that someone can took from the plugin the security data, why dont you just create your own database and connect the plugin with that database in a live/cloud model? You could even have your database and other databases at the same time like WPscanner database and join them in the cloud/live scanning.

I really dont understand this fat client approach. And it is bad, because it will take time for you to include new data and put it online. and then for we to update and run it again.

You can even go further and make your clients register using the plugin so that they can get new security data after install (a free registration). This way you would get a unique register number (generated by the plugin) and control the uniqueness of it.

thank you

@tdmalone

We wouldn’t have made the plugin if we didn’t want the data used, the issue here is with people taking our data and putting it in to their own plugins.

We are a business and need to justify our time, so it does actually make sense for us get the “glory”, as you put it, for all the work we do since otherwise don’t have a justification to continue to do the behind the scenes work of the larger project this plugin is the samll public face of. If somebody else wants to do that work they could already be and don’t need to collaborate with us to get it done since anyone can test and report a publicly disclosed vulnerability to the developer of a plugin or the Plugin Directory, it just doesn’t happen much, which is unfortunate because more eyes on this would be better. Someone taking our data wholesale and putting it to their own plugin isn’t collaboration.

@fwu

If the data is in a database that is publicly accessible others can copy it (they may have to do it a plugin at a time though), so making the plugin more complicated to try prevent that doesn’t accomplish much.

Our plugin is designed to be used in conjunction with keeping your plugins up to date. If you are not keeping your plugins up to date you are going to have a bigger problem than not having the latest data for our plugin as our plugin can only possibly warn about publicly disclosed vulnerabilities, so if a developer fixes a vulnerability and no one discloses it wouldn’t be possible for our plugin to warn about it.

We also try to make sure the developer has been privately notified about an unfixed vulnerability before we add it to our plugin, so the developer has a chance to fix it before we provide more attention to the vulnerability. We also do that because it is lot more useful for the plugin to be fixed than for us to warn people about an unfixed vulnerability and for them to have to decide how to handle it.

If you turn on automatic background updates for plugin using our Automatic Plugin Updates plugin or another method and turn on email alerts in this plugin, then the updates and checking should occur seamlessly behind the scenes without requiring any interaction on your part.

By the way, your plugin is released under the GPLv2 (as it should be, being derivative of WordPress).

So asking people not to take the data and use it kinda defeats that!

This thread isn’t really relevant to the current state of the plugin, seeing as most of the vulnerability data was to moved to a centralized database accessible through our Plugin Vulnerabilities service back in version 2.0.