Item12137: Invalid regular expression entered by admin causes configure to crash

An externally-supplied regex causes a die in Types/REGEX.

This is a cousin bug to one fixed in Checker.pm a while ago.

Both come from a common coding mistake, so I'm giving a history lesson to help instill caution:

It's assumed that qr/$value/ is safe. In the previous case, we tried to be clever, and did eval "qr/$exp/"; this blew up on valid REs that contained '/' -like X509 names. eval "qr/\$exp/" is safe, though I prefer to actually use the expression, as in eval " 'x' =~ $exp "; Nothing like a use test.

Tonight's bug is in string2value, where after stripping some noise out of the assumed re, we just return qr/$value/. qr compiles the re - a value like '((" (my test case) blows up. Here, the fix is to eval the qr; if it fails, hand off the input string (which will be fine for most purposes, including handing it to configure's checkers). Otherwise, return the result of the eval.

Moral of the story, don't ever trust qr on data that someone else provides.

I'm checking this in as a bugfix. (The patch, not the lecture.)

Leaving as "needs merge" as it should go in any patch release.

-- TimotheLitt - 11 Oct 2012

Commenting is disabled while not logged in