Site icon WebDevStudios

Releasing Plugin Updates and Handling Security Vulnerabilities

Ben Lobaugh
WordPress, WordPress plugins, webdevstudios, how to submit a plugin, WordPress repository, WordPress tutorial, WordPress how-to
In my last article, I walked you through getting your plugin up and running on the WordPress.org plugin repository. In this follow up article I want to talk about releasing updates and new versions of your plugin.
I will also touch on the topic of security vulnerabilities and how to deal with them, which is a frightening topic for many people but by following a few simple steps you will save yourself a lot of stress and look like a hero to your users.

Tags vs Trunk

When you are contemplating releasing a new version of your plugin you will inevitably be faced with the question, “Do I release from trunk or create tags?” I am going to provide some high level pros and cons and then walk you through the process of both styles of development.

Trunk

Pros:
Cons:

Tags

Pros:
Cons:

Now that you know the pros and cons, I will tell you that, after releasing dozens of plugins on the repository, the couple extra hoops you jump through during a release when using tags is well worth the effort and is the method I recommend.

Let’s walk through examples of using both types of release models.

Developing in Trunk

Developing and releasing new versions of you plugin from trunk is the simplest method. On a small plugin with not much functionality this could potentially be a good method to use.

In the last article, you saw how to push your plugin code to the WordPress.org repository; your process will be nearly identical now:

When you are ready to release your new version there are a couple things to remember:

You can commit the plugin with the following command:

svn ci

Tagging

As previously mentioned, using the tagging method for releases is a bit more complex but the benefits far outweigh the advantages. Let’s dive right into tags.

When using tags, you no longer think about code in trunk being releasable code. Trunk becomes your code playground, the place you can build and test new features. Trunk does not need to stay in a stable state–though you should still endeavor for it to be.

Here’s an example that assumes you have already completed development in trunk for the version 2.0 release:

Update readme.txt

Now is a great time to update the readme.txt with the details of your new plugin version. Be sure to check the following.

Update plugin version

Open the main plugin php file and update the version number.

Create the new tag

When you create a tag, you are actually copying all of the files in trunk to a new folder inside of tags. It will look something like:

svn cp trunk tags/2.0

Commit the update to the WordPress.org repository

Everything should now be ready to go to release the plugin! All that remains is pushing back to the WordPress.org repository. Run the following command and provide a release message and you plugin is on its way:

svn ci

It may take a few minutes for the WordPress.org repository to pick up your changes. When it does, a new archive of the plugin will be created for download and you will see the new version number along with the updated readme.txt when visiting the plugin page.

Your plugin users will recieve an update notification next time they log into their WordPress dashboard.

Oh no! A security vulnerability was found!!! What do I do????

Crap happens; relax!

As long as you (and your team) continue to be human you will make mistakes. The important part is how you deal with issues when they come up. Before you can effectively deal with this crisis, take a moment to breathe. Center yourself–go for a short walk to reflect if you need to. This stuff happens to everyone eventually.

This even happens to large projects such as Jetpack and Easy Digital Downloads. Heck, WordPress Core recently released an update to patch an XSS vulnerability. At some point tor another we will all experience a security vulnerability. With two decades of development quickly closing in on me, here are some tips I learned from situations I have been in (and some lessons I have learned from watching others).

Breathe, relax

When a vulnerability presents itself, your first instinct is to tense up. Panic sets in, sweat appears on your brow, and likely your body temperature spikes. This is a normal reaction but not helpful to resolving the vulnerability. While your body is in this mode, the critical thinking you need goes out the window. So sit down for a minute and breathe. Let your body come back to its normal state and your brain clear up a bit.

Identify the solution

Read through the vulnerability report again and make sure you understand what the vulnerability is and how it can be exploited. If you can, setup some tests that will automatically try to exploit the vulnerability for you. This will allow you to quickly test your patch.

As you work on your patch, get some trusted associates,be they other team members, people in the WordPress community, or friends, to test it for you. Another set of eyes can only help find solutions.

Work with the WordPress.org Security Team

Did you know the WordPress project has a team of security experts standing by to help you? The WordPress team takes security very seriously and they want to help you. What is good for your plugin’s security is good for the whole community. You can get ahold of them at plugins@wordpress.org.

The WordPress security team will protect your privacy. You do not need to be concerned about details leaking before your patch is ready.

Additionally, the security team will work with you to push out automated security updates to all users affected on modern WordPress installs.

Post your patch

On one hand, you need to get a patch out to close the security vulnerability as quickly as possible, but on the other, you need to make sure your patch is as thoroughly tested as possible. You are your product’s best advocate and expert so I will leave details of patching your plugin up to you. At this point, you should already understand the process of releasing an update. Reread the first part of this article if you would like a refresher.

If you would like additional support or help creating your patch, or a general code review of the patch and plugin itself, we here at WebDevStudios would be happy to assist you. Send us a message on our contact form or tweet us @webdevstudios.

Own it

Above all, the WordPress (and open source) community at large value transparency. We all know and understand that vulnerabilities can and do happen. If you are open and honest with the community and your users you will earn their respect and they will be a repeat customer.

Earlier, I linked to the Jetpack and Easy Digital Download vulnerability announcements. How you want to word your announcement is up to you. Provide enough details so your users understand the urgency of updating the plugin with your patch but you probably do not want to go so far as to tell everyone how to run the exploit. The unfortunate reality is that not everyone updates their plugins in a timely manner, and by revealing how to run the exploit, you could inadvertently give hackers the exact tool they have been looking for to take out your user’s website.

Get the message out

Now that your patch is out, it is important to get as many users updating as quickly as you can. Use every means at your disposal to get the message out far and wide. Here are a few likely channels of communication:

Sucuri has become one of the most widely respected security companies in the community. Thousands of people see their updates, and Sucuri is a great place to amplify your message. Sucuri also does a great job of post ops and helping others understand the severity of the plugin.

Enjoy your success, fame, and fortune

Well now you know how to release new updates to your plugin to continually improve them and how to deal with security vulnerabilities. All that is left is that big idea that will make you the big $$$. Good luck to you. Do not forget about me when you have become rich and famous!

Exit mobile version