Releasing Plugin Updates and Handling Security Vulnerabilities

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:

• Single simple workspace
• You do not have to worry about running additional svn commands and hoping everything is copied properly
• To release a new version all that needs to be done is the plugin version number updated

Cons:

• Not easy to switch between versions of the plugin (remember *gasp* not everyone updates)
• Impossible to release security patches for previous versions with vulnerabilities
• Fragile–you rely on the repo to figure out when it is safe to create a new release for downloading instead of explicitly telling it where the release code is

Tags

Pros:

• Easy to go back and find any version of the plugin released
• Security patches and bug fixes can be back-ported into previous versions to ensure your users are not left out in the cold
• Development still happens in trunk but it is a clean sandbox that you do not have to worry about users accidentally installing from if code is broken or in progress
• With tags you can create beta releases that users can download and test for bugs

Cons:

• More complex to release a new version than releasing from trunk
• Version numbers need to be updated and verified in a couple places to ensure the repo knows about the new release
• The developer checkout of your plugin repo will grow large quickly

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:

• Develop
• Develop
• Develop
• Commit your changes
• Alter the plugin version numbers
• Drink Scotch while your users enjoy their new functionality

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

• Update the plugin version number in the main plugin php file
• Update the contributors in readme.txt
• Stable tag is trunk and should remain trunk
• Update Tested up to in readme.txt to the version of WordPress you have tested the new version on
• Update the Changelog in readme.txt and add in details of the changes to the plugin
• Commit the plugin back to the WordPress.org repository
• That is it, you are done!

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 the contributors in readme.txt
• Update the stable tag to 2.0
• Update Tested up to in readme.txt to the version of WordPress you have tested the new version on
• Update the Changelog in readme.txt and add in details of the changes to the plugin

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 [email protected].

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:

• Your email list
• WordPress.org support forum
• Facebook
• Twitter
• Sucuri

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!