June 2015

You are browsing the site archives for June 2015.

When I first created OpaqueMail, I faced the difficult choice between S/MIME and PGP as the standard for encryption.

The advantages for S/MIME were:

  1. A lower barrier of entry due to supporting libraries pre-installed with Windows.
  2. Greater familiarity and ease of use for developers used to public key infrastructure.
  3. Lower complexity of managing, securing, and choosing keys.

S/MIME adoption has grown, partly thanks to the usability of OpaqueMail, but it remains prohibitively complex for many scenarios.

Email is being increasingly secured through PGP. I don’t have reliable data, but PGP seems to enjoy wider adoption and awareness from the general public. I’ve wanted to support both for a while now, but needed a good reason to embark on the PGP path.

A tipping point for me this month has been Facebook’s new support for publishing PGP keys.  Finally, there is a public, (largely) trusted database where users can share keys. Instead of the traditional “web of trust”, I expect key databases (like keybase.io) to foster increased adoption.

With that background, I’ve started adding PGP support to OpaqueMail, now available to test in the 2.2.0 release. For the first time, OpaqueMail now has a dependency on another open source library: BouncyCastle. PGP is far too complex to implement from scratch and thankfully BouncyCastle provides secure, high-performance, and complete libraries for cryptography. The Legion of the Bouncy Castle dates back to the 1990s and their code has been scrutinized by tens of thousands of developers.

OpaqueMail 2.2.0 features PGP decryption and signature verification only. Encryption and signature creation is planned for a future release.

Beyond that, I may start another project to streamline public key discovery from Facebook and other federated sources.

Now that your WordPress Multisite install is up and running in Azure using Project Nami, it’s time to set up daily backups.

WordPress Files

For your files (code, uploads, and other multimedia), it’s easy. Under your Web App settings, choose “Backup” and create a schedule. In my case, I went with daily backups (retained for 30 days), backed up in the same resource group in the same region. With about 1 GB of files, backups complete in under 10 minutes.

WordPress Database

Now what about the database? Normally, I’d just set up a linked resource so the database would get backed up along with the website. Unfortunately, that doesn’t seem to be working in my subscription (and there are more than a dozen threads complaining about the same issue on TechNet).  When I select a database to be backed up with my WordPress site, it fails instantly with a vague error in the operations log, leaving me with a 0 MB backup.

As a backup, I figured I’d just set up a scheduled database backup that would be saved on the filesystem, which would be part of the files backup. Well, it turns out that most of the mature WordPress backup plugins (e.g., WP-DB-Backup, BackWPup, BackUpWordPress) don’t support multi-sites and/or don’t support Project Nami. So that option’s out.

Fortunately, Azure databases on the basic, standard, or premium tiers are automatically backed up hourly and provide 7, 14, or 35 days of retention. Using an S1 instance, I’m more than comfortable with a 14 day database backup window.