[lug] Perl question: how to print embedded metacharacters

[Tkil]

>>>>> "Tkil" == Tkil <tkil at scrye.com> writes:

Tkil> (Perl 'eval' is also substantially slower than the simple hash
Tkil> lookup I describe below, but the security implications alone are
Tkil> enough to keep me from recommending it.)

>>>>> "Rob" == Rob Nagler <nagler at bivio.biz> writes:

Rob> bOP has been using eval ("do", actually) for about 10 years now.
Rob> I don't think there are any security implications to using eval
Rob> unless your system allows end-users to write files to arbitrary
Rob> locations.  

Or if you're doing server-side processing on behalf of users.  Either
way, using "eval" on any input that isn't completely under one's
control opens up the same security issues as with SQL injection
attacks.

Rob> Yes, this is security through obscurity, but the "million doors"
Rob> problem is a real phenomenon.

True enough.  But in this case, it seemed fast and cheap enough to do
a minimal job that might still be faster and more secure than 'eval',
so why not?

Rob> I don't think speed is an issue.  The Freikometer [...] could
Rob> have cached the config file, but it turns out that it works just
Rob> fine as it is.

Sure.  And the cost of I/O is much higher than the cost of perl
parsing, so once the config file is in cache, the perl parse is
[relatively] quick.  On the other paw, 1GHz CPUs are still relatively
new to the embedded space, and use more power than a slower CPU -- so
even though absolute "time elapsed" performance might be sufficient,
bringing in other criteria might change that answer.

(And going further down that path gets one coding in C or assembler,
yes.  I know.  :)

Rob> I find it hard to believe that performance would ever be an issue
Rob> with config files, esp. if you are using Perl's eval.

Rob> When in doubt, measure it.  The same is true for security. :)

Apples and oranges, IMHO.  You can define performance (time to render,
time to completion, power/wattage consumed, etc) and then measure and
figure out what's the best tradeoff for your current situation.

Security, on the other paw, is not a closed problem; adversaries come
up with new attacks all the time.  That's why I recommended a "white
list" approach in this case.

Anyway.  Use cases vary, and the amount of time one wants to spend on
analyzing costs also varies.  I'm pretty much done here.  :)

Happy hacking,
t.