[quote="Mongrel"]As I said, I'm a total n00b concerning Perl. Until today I only knew that it existed somewhere, hehe.
Mind you, I'm not trying to stir up shit here, just trying to help. "Perl worms" were the first thing that came into my mind after reading the previous posts, so I just wanted to mention it.
[quote]
Don't sweat it... it is a valid concern.
Quote:
|
What exactly is the difference between Perl and embedded Perl (embperl)?
|
The only real difference is that embedded perl is embedded into another program in some way. You should be able to do everything (and then some) that a standalone perl script could do.
Quote:
|
I looked around on perl.com and /perl.apache.org/embperl for a bit, but couldn't find an exact explanation of the differences.
|
There isn't too much info on it. I am only aware of a handful of popular programs (2 irc clients, Apache, a few others) that have full-fledged native perl interfaces (as opposed to wsh interfaces).
Quote:
|
Perl has lots of low level IO functions, embperl doesn't seem to have these. Is embperl just an addition to normal Perl featuring all functions of its "father"?
|
No, this implementation can do everything that standalone perl can do.
Quote:
|
If so, it might be a good idea to block their use in EQEmu.
|
I doubt it. At present (assuming the #peval interface is not avaliable), there is no way for an end-user to directly inject their code into perl. To be subject to most errors, you would have to have bad quest code. If you are really worried about security, you would have to review each quest. Otherwise, you are implicitly trusting the authors (just like with eqemu itself). The bottom-line is that in most cases a user would have to have already compromised you system with a priviledge escalation attack in order to abuse perl. To the person who can already do this, perl's avaliability is only a slignt convenience.