David Oswald

A call to action for CPAN authors

2013-05-22T14:50:41Z

CPAN authors should look at the smoke tests for their modules to ensure that they're passing on Perl 5.18. The hash randomization change (and a few others) has bitten many a module that may currently be relying on undefined hash behavior. If you haven't checked your modules recently, you may be in for a surprise.

The problem is significant, especially when compounded by the fact that a single misbehaving module can block many more modules that may depend on it.

As an example (not to finger-point, but just to illustrate): Crypt::DES, Crypt::IDEA, Crypt::Blowfish, and Crypt::Twofish had a single line of XS code that was incompatible with Perl 5.18 (which happened to not be related to hash randomization). As a result, all modules that depended on any of these modules also would fail to install on Perl 5.18. This includes Authen::Passphrase, and Crypt::OpenPGP, as well as dozens of others.

For awhile during Perl 5.17 development Perl 5 Porters were keeping a list of modules they were aware of that had bugs made evident by the hash randomization change. But given that we've been hearing warnings about relying on undefined behavior for years, and in particular warnings about hash randomization for many months, at some point it stops being Perl 5 Porters responsibility to keep track of modules that have bugs.

In many cases, these bugs are in modules' test suites, and not the modules' primary code. But whatever the case, we need to be diligent in ferreting out such problems and resolving them. Having a good portion of CPAN break because of a number of modules relying on undefined behavior is one of those "egg on our face" moments that we need to wipe off and put behind us.

If you know one of your modules has begun failing on Perl 5.18, I encourage you to fix it. If you know of an unmaintained module that has begun failing, follow up with the author, or seek to take over maintenance. Report problems to the RT system. Contribute patches. Let's work together to get this problem resolved as quickly as possible.

A call to Salt Lake City prospective Perl Mongers

2013-03-04T19:28:30Z

I have enjoyed actively participating in the Los Angeles Perl Mongers and Thousand Oaks Perl Mongers groups, but recently relocated to Salt Lake City, UT. So, what stands between Salt Lake City and a Perl Mongers group? You (you know who you are). Anyone interested in participating in a Perl Mongers group in Salt Lake City, please follow-up here or get in touch with me via email.

A request has been submitted to the folks at pm.org for a mailing list, a pm.org hosted site, and a link to the main pm.org map page. Since those nuts and bolts are fastened by volunteers it takes awhile. But we don't have to wait. The time to start organizing something is now.

Perl Mongers groups provide excellent opportunities to get to know others in the local Perl community, to introduce newcomers to Perl's many ways to do it, to learn, to share, and to socialize.

Bytes::Random::Secure -- A no-fuss CSPRNG.

2013-02-13T00:23:04Z

There are a lot of contributions on CPAN that fill one niche or another with respect to pseudo-randomness generation. What is hard to find is a solution that provides cryptographically secure pseudo random number generation, reliable and strong seeding, a light-weight dependency chain, and cross platform compatibility through a wide range of operating systems and Perl versions.

Bytes::Random::Secure is one of those modules that gets written to fill a personal need, and then begins to take on a broader life of its own. As is often the case, the contributions of others in the community have served to improve the module beyond its original specifications. Dana Jacobsen provided a lot of suggestions, and even went so far as to create a new seeding module (Crypt::Random::Seed) which helped Bytes::Random::Secure to reduce its dependency footprint greatly.

Bytes::Random::Secure starts with a simple user interface based on Bytes::Random, and adds a more suitable randomness source, and some additional utilities. Its RNG comes from Math::Random::ISAAC, and its seeding comes from Crypt::Random::Seed. Its most useful functions are probably random_bytes(), random_string_from(), and irand(). By using its OO interface the user gets finer control over seeding characteristics, though an attempt has been made to choose safe and sane defaults that should be reliable out of the box with no configuration.

The specs: An ISAAC CSPRNG, strong seeding, only three non-Core dependencies, compatibility with Perl 5.6 and newer, and support for all common platforms. ...and for a CSPRNG, it's pretty quick, especially if the optional Math::Random::ISAAC::XS dependency is installed.

Creating a Perl web application on dotCloud

2012-08-29T23:15:00Z

I've been working on a project for a client that is being hosted on dotCloud. And as part of the process I have spent a good deal of time familiarizing myself with this PaaS provider. My experiences thus far have been quite positive. I've found dotCloud to be highly receptive to working with Perl developers, and they seem to value building a relationship with the Perl community.

A few weeks ago I gave a presentation to Thousand Oaks Perl Mongers, and last night another presentation to Los Angeles Perl Mongers discussing using dotCloud with Perl. There were a few simple examples based on Mojolicious.

The Libre Office Impress slides along with a working example are on Github. Another working example, the Perl Regex Tester also has a public Github repo.

The presentation's slides (which were reviewed by dotCloud for accuracy) are viewable on slideshare.