WordPress ought to issue deprecation notices, really

Agreed. I think that at a certain point, wordpress needs to come up with a simple way to make it so that ancient and unsupported plugins and themes cannot be used or at least cannot be EASILY used on current installations.

I agree, there should be warnings on the admin panel when plugins are getting old. I also think that wordpress should work to try to keep in contact with developers and ask them to update their plugins from time to time, at least to confirm that they are “live” and maintained. Plugins that don’t get checked by the authors should be marked as “not maintained”, which would discourage the use of plugins that might cause future issues.

I think it’s important to also distinguish between old and abandoned, just because a plugin hasn’t been updated doesn’t mean it no longer functions or is abandoned, it could mean it doesn’t need updating.

As more and more devs switch to the philosophy of a single plugin for a single function, you are going to find lots of very small, few lines of codes that do the job today and will continue doing them in ten years time if you let them.

Are these becoming less secure as they age? while possible it’s unlikely.

Indeed an argument could be said that older, stable battle tested reviewed code that doesn’t get constant updates and changes is a good thing.

There is an argument that historically code reviews before plugins were approved on w.org were sketchy at best, thats no longer the case and every plugin is reviewed initially however the changes are not. So you could draw a line and say anything pre 2010 is a wee bit suspect.

But remembering on the first update which could change 100% of code is not reviewed before pushed the argument older a plugin less secure doesn’t hold much weight, as the more recent the plugin update the less eyes will have been passed over it, the more likely you could argue a security hole will develop.

This is especially true as plugin features increase as does the codebase. So something that entered the repo as a small little thing of a few hundred lines of code. Can easily spawn thousands of lines of unreviewed code just one iteration later.

So within the repo, you are looking for small plugin, with limited codebase, which has never had an update and has been approved in the last couple of years. Even then you are relying on a human and some automated tests spotting issues.

If we applied that ruleset and flagged everything else, we would have a pretty robust secure(ish) set of plugins and an awful lot of angry folks wanting all the features of the thousands of other plugins.

Code review is important, but by it’s nature, code review could also be part of a solution to tell the difference between dead code and old code that still does the job. Right now, there is no simple way to tell.

The issue of the genericons (and others in the past) are particularly important in an older code base. How many of the themes currently on wordpress.org for download might have this code in it? Based on what I see in server logs, there is plenty of bad stuff out there, and the script kiddies are out there hammering away at it. From my current experience, more than 20% of the current spam and attacks on wordpress sites now comes from other compromised wordpress installs.

At some point, there needs to be a better way to tell good from bad without having to just take your chances.

” In any case, the WordPress core upgrade yesterday has a routine that goes through looking for that particular file in all themes and plugins, and then it deletes it.”

Would that be on all upgrades, or only those using the automatic upgrades?

Otto, only “ALL” for the code that you have added in this particular case.

Did update get rid of all the extra stuff in Yoasts plug ins?

“I don’t know what you’re talking about with regards to Yoast’s plugins. Nor is that really relevant, as Yoast’s plugins are not part of the WordPress core.”

Alas, this is the problem. For end users, WordPress is a “thing”. They may not see the shades of grey different between core and plugins or themes, especially considering that plugins like Akismet (and hello dolly, woo hoo!) are part of the core, and themse such as twenty twelve and such are distributed as part of the core updates. Moreover, some of the most popular plugins (like Jetpack) are “in house” products. So as an example, as you dismiss the Yoast issue, your code code has been cleaning up in themes and plugins. Without reading the code, how would a site operator really know?

My take is generally simple, I assume that none of it gets fixed, and I make sure I fix it myself (a couple of hundred times per update… ). So things like questionable sliders, random upload code, and the like all has to be removed to avoid opening security holes. As there is no way to be certain that a plug in or a theme will delete unused files, the only way to handle them properly at this point is full delete and re-install.

A significant amount of the security issues with WordPress are not in core, but in how plugins work and the code they bring to the table. For the moment, there is no simple way to know if a theme or plug in, even downloaded from WordPress site itself, is safe or tested. The security risks of those products reflect on the whole of wordpress as well.

WordPress has an updater for core – yet updating themes and plug ins is basically copy over and that’s it. No way to know if all the files were fixed, no way to assure that old files were removed, and so on.

Yes, I know… it’s not core. it also doesn’t help make wordpress look very secure.