Skip Menu |

This queue is for tickets about the Hash-AsObject CPAN distribution.

Report information
The Basics
Id: 32146
Status: resolved
Priority: 0/
Queue: Hash-AsObject

Owner: nkuitse [...]
Requestors: rafl [...]

Bug Information
Severity: Important
Broken in: 0.09
Fixed in: (no value)

Subject: Don't use string eval
Download (untitled) / with headers
text/plain 1.5k
You use string eval to store autoloaded methods in the symbol table automatically. This is not only a big performance penalty as the compiler needs to be fired up again during runtime, but it's also a security risk: my $meth = q[;print qq/code injection\n/;]; Object::AsHash->new->$meth; The above causes the print statement to be executed, which is harmless in that case, but using other, possibly malicious code snippets, as hash keys and therefor as method names, might lead to unexpected results. Why are you using string eval? In case you only use it to store the generated method in the symbol table you can excange it by the following statement which uses typeglobs and code references: { no strict 'refs'; *{ $key } = sub { my $v; ...; # and so on }; } This has the advantage of being - more secure any userdefined input like the hash key/method name can't result in invalid perl or malicious code as it can when you're putting together the code at runtime yourself - faster no compiling at runtime - easier to maintain the syntax is checked at compile time and your editor and other tools may use that to indicate errors. Also you get rid of quite a lot of quoting you currently need to do. In case you're using the string eval just to catch exceptions you might want to consider switching to block eval instead: eval { your(code => $here); }; The same reasons as above apply. Please let me know if it would help you if I provide a patch with tests.
Fixed in 0.10. Thanks for reporting!

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to