While I have hung out on the fringes of the p5p and toolchain communities for a few years now, my largest “qualifying” contribution has been Alien::Base, which has largely been handed off to Graham Ollis (plicease).
Therefore I was a little surprised but very honored to be invited to the 2016 Perl QA Hackathon held in Rugby, England.
Overall it was an incredible experience.
Day after day the energy in the room was palpable.
Everyone was creating and improving the code that we would all get to use one way or the other.
People hacking on PAUSE and MetaCPAN and CPANTesters, on ExtUtils::MakeMaker, on Test2 and Test::More.
In a future post I will recount the details of my delightful experience at the 2016 Perl QA Hackathon (N.B. now published here).
Since this is my first post since that time I do want to tip my hat to the great sponsors of the event and to my own employer ServerCentral without whom I would not have been able to attend.
I will thank them in more detail in that post.
Before I get to that however, I want to post a reflection on one discussion that is and has been weighing on my mind since then.
That topic is the upcoming release of Test2, which I consider to be a very important step forward for Perl’s testing architecture.
There has been some discussion this week about forks of pieces of Mojolicious.
Frustrating discussions over what is proper and how to discourage forking.
It has been a long week to be honest (and thankfully the recent incident has been peacefully resolved, see postscript).
But then finally, just today, I’ve chosen to see things a different way.
I’m really happy to see what lengths people are willing to go to in order to use Mojolicious.
This includes addressing a perceived need for streamlining by taking a maintenance burden onto themselves and forking that code that which they need.
They see the value in Mojolicious’ code, if not the value in the toolkit as a whole.
I’m assuming that by now you’ve probably heard of Let’s Encrypt.
If you haven’t, they are a brand new Certificate Authority that issues SSL certificates for free via an automated system!
There has to be a catch right?
Well kinda, but it’s a small one.
The certificate is only valid for 90 days.
They mention two reasons for this in a blog post: to encourage automation and to contain the damage of a compromised cert.
If you need to renew every 90 days, you don’t want to be doing that by hand right?
By encouraging automation, they can effectively force you to investigate how to make security easier for yourself over the long term.
You may have read the famous Ten Immutable Laws Of Security but the related Ten Immutable Laws of Security Administration tells us in Law #2 that
Security only works if the secure way also happens to be the easy way
Once you have automated your SSL cert generation then the easy way will be the standard way.
Also, the shorter the duration of the cert, the less time that a compromised cert can be used to wreak havoc.
But once we all have automation, they can actually tighten that time eventually to even shorter times, which would further contain the damage of compromised certs.
So let that sink in: all you have to do to have a secure website for free is to setup the automation to issue and renew the certificate.
The article itself is published at PerlTricks. This is the second article I’ve published there (the first was about How to send verification emails using Mojolicious). Hopefully more to come!