Posted on
by

Just a quick post to bring you an update on the email posting support for Idno.

The email posting plugin is a handy plugin that allows you to make posts to your Idno site via email. Unfortunately, since the way POSSE syndication buttons worked was changed a little while ago, it hasn’t been possible to post out to your silo followers in twitter/facebook/etc.

No longer! Now, you are able to specify a syndication destination by putting one or more pipe tags in the email subject line (these will be removed from the post). So, for example to post to twitter, you’d use the “|” (pipe) character before the service, and add a |twitter to the subject line.

Have fun!

» Visit the project on Github...

Posted on
by

So, unless you have been living under a rock for the last few days, you would have heard about Heartbleed, the recently discovered OpenSSL security bug (go over to XKCD for the best explanation I’ve seen for how it works).

It was bad, really bad. As Bruce Schneier put it:

“Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.

…And it was, very bad, but it could have been much much worse.

As it was, within a day or two of the bug being declared, the vast majority of affected servers were patched, and service users notified. We don’t know how often, if at all, this bug has been exploited, and we likely never will, but we can easily tell if it’s been fixed.

Bugs happen, but the only reason we know about Heartbleed at all is because OpenSSL is Open Source software. Open source allows you, and other third parties, to independently review and audit the code, something not possible with software from proprietary vendors.

Does software from Apple, Google or Microsoft contain similar ticking timebombs? Who knows, and we have no way of finding out. This is one of the many reasons why you should never trust closed source or proprietary security products. Ever.

Bluntly, anything where you can’t see the code can’t be audited, so can’t be trusted not to do something malicious, whether by accident or design. Trusting a product from a manufacturer purely on brand is a genetic fallacy.

What next

OpenSSL is an incredible project, and the community do a bang up job at keeping our communications safe from prying eyes. The fact that this bug, a simple buffer overflow error (a mistake every C programmer has made countless times in their career), was not spotted for almost two years is a little troubling, but those of us outside the project can’t really comment usefully on that.

Bugs happen, sometimes they’re serious, but the responsible action was followed and internet security is stronger for it. Patch and move on.

Talking specifically about OpenSSL, and open source in general, my thinking is that Heartbleed highlights a resource problem common with many projects which fall under the umbrella of being “infrastructure”. In that, it is largely built by volunteers (although also with large contributions from engineers paid to work on the project by their day job), and so sometimes there’s not enough bandwidth available to do everything, but by being “infrastructure”, doesn’t get so much of the attention as the latest wizzbang project on Hacker news.

My hope is that this bug will see more stakeholders taking an active interest, and so see a growth in the numbers of contributors and auditors. If every company who relied on OpenSSL paid one of their engineers to spend one day a month trying to break it, or audit the latest code, how many more person-hours this would give the project?

Another issue Heartbleed illustrates painfully well, is the danger of homogeneity. When the vast majority of the world use the same bit of software, it presents a single point of failure, and one error can have a massive impact.

OpenSSL has become the de-facto standard SSL/TLS implementation in use through merit, and while there is a very good case for not rolling your own crypto, I wonder if there is a case for encouraging and maturing different open source implementations of the protocol? Pros and cons on either side, but single points of failure should always be avoided…

Image “How the Heartbleed bug works” by XKCD

Posted on
by

Following from a similar post, where I packaged up my standard web services libraries to avoid repeating myself, I decided to do the same for Events and triggers.

Events provide a very powerful, flexible and simple way of providing hooks for other code to attach to, in a loosely coupled way. I’ve been using event driven development in my PHP code for years, way back since the first days of Elgg. In Elgg, events and triggers proved to be one of the frameworks most powerful, and a major factor in its success, allowing plugin developers to easily change core functionality without changing a line of core code.

Anyway, I’ve used Events in one form or another in pretty much every framework since, and I’ve found myself increasingly cutting and pasting code around, so I figured it’d be sensible to package this up into a reusable library as well. Although it is designed to be simple, the library is pretty powerful.

One particularly useful feature is that event listeners can include regexp!

Triggering an event…

If you were writing a framework that had users for example, and you wanted to allow plugin authors to hook in and do something when a new user is created, you might do something like this in your registration code…

function registerUser($username, $password) {

    ...
    // User creation code here
    ...

    // Ok, now tell everyone that a user has been created
    \simple_event_dispatcher\Events::trigger('user', 'create', ['user' => $new_user]);

}

Listening to an event…

So, if you wanted to listen to the user creation event inside your plugin…

// Register an event for every time a user is created
\simple_event_dispatcher\Events::register('user', 'create', function($namespace, $event, &$parameters) { 

    // Your code here

});

You can replace any part of the $namespace or $event string in Events::register (‘user‘ and ‘create‘ respectively in the example above) with regular expression. So, you could, for example, replace ‘user‘ with ‘*‘ to listen with any create event.

Code on GitHub, have fun!

» Visit the project on Github...