loading...

Blog post: Static Analysis in Perl - or yet another policy

jonasbn profile image jonasbn ・2 min read

After writing my last blog post: "Bugs!? - static analysis to the rescue" I checked my list of blog posts and I discovered that I had never blogged about another Perl::Critic policy I had recently implemented.

The idea for the implementation was again not really my own, but was triggered by a tweet back in June 2018 by Joelle Maslak (@jmaslak).

Perl folk: Looking for a PR challenge task? Check for \d in regexes that really should be [0-9] or should have the /a regex modifier. Perl is multinational by default! #TPCiSLC

After reading the tweet I thought a Perl::Critic policy sounded like a good solution since we want to keep potential problems out of our code bases permanently and static analysis is a good process and tool. So I implemented Perl::Critic::Policy::RegularExpressions::RequireDefault.

The policy's goal is to recommend the use of built-in improvements introduced in Perl 5.14 for regular expressions to avoid potential issues with:

  • Visual Spoofing
  • Character and String Transformation Vulnerabilities

Both aspects being security issues related to Unicode. I have actually never found out who implemented the feature in Perl, but this policy is simply leaning on this implementation so kudos to the Perl maintainers for implementing this, providing facilities to write more secure regular expressions in Perl, my policy simply tries to recommend the use of the feature for regular expressions - it is still up to you to decide whether it suits your code base :-)

The policy is uploaded to MetaCPAN and is available via CPAN, but I am pondering attempting to get it adopted in to Perl::Critic core.

Do let me know what you think - PRs and feedback most welcome...

Posted on Feb 2 '19 by:

jonasbn profile

jonasbn

@jonasbn

Computer programmer, runner, LEGO builder, powernapper, yakshaver and father of 2 boys all squeezed in the few hours available.

Discussion

markdown guide