"Selling" Perl (i.e. getting the boss to let me install it)

[P B]

Hello,

I'd like to install ActivePerl on a Windows XP machine specifically to
run a particular script. The "problem" is that the admins in charge of
the PC are very cautious about what is installed and the security
implications of everything (as they should be).

I thought I recalled seeing a perlfaq specifically regarding this issue,
but several `perldoc -q' searches and a perusal of the perlfaqs posted
here were fruitless. (Besides the sort of general "How do I convince
others to use Perl?")

Can anyone provide a link or perhaps a little narrative about why Perl
is safe and secure to install (I'm talking about the Perl interpreter,
specifically the ActivePerl build here, not any scripts that may be
run).

Also, the script that I'd like to run if I do get Perl installed uses
WWW::Mechanize. Are there any links, resources, opinions, or first-hand
experiences as to the security implications of this particular module?

Thanks,

PB

 

[John Bokma]

Hello,

I'd like to install ActivePerl on a Windows XP machine specifically to
run a particular script. The "problem" is that the admins in charge of
the PC are very cautious about what is installed and the security
implications of everything (as they should be).

You have limited access rights, and Perl will run with your rights. Hence
it doesn't provide you with any magic. If your admins don't get it, they
shouldn't admin computers in the first place.

That being said, you probably can just install Perl in your own directory,
one way or another.

 

[A. Sinan Unur]

You have limited access rights, and Perl will run with your rights.
Hence it doesn't provide you with any magic. If your admins don't get
it, they shouldn't admin computers in the first place.

That being said, you probably can just install Perl in your own
directory, one way or another.

Ditto.

You can also pack the script into a self-sufficient exe using pp:

http://search.cpan.org/~smueller/PAR-0.982/lib/PAR/Tutorial.pod#Perl_Packager:_pp

The executable would not need any elevated privileges other
than being able to read/write your account's %TEMP%.

Sinan
--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

 

[Dave Everson]

Look for a new job. Seriously, if you work in an environment in which
installing Activestate Perl requires permission you probably aren't in a
place that will let you be successful.

 

[John Bokma]

Look for a new job. Seriously, if you work in an environment in which
installing Activestate Perl requires permission you probably aren't in a
place that will let you be successful.

IMNSHO that's quite an over the top statement.

 

[cartercc]

All languages are simply tools, nothing more. As such, you need to
relate a job and a tool. If all you do is pound in nails, you don't
need a wrench. If you fasten bolts, you need a wrench, not a hammer.

Your manager will probably tell you that you should use the 'best'
tool for the job. 'Best' can mean many things, e.g., the tools that
you have are better than the tools that you don't have, the tools that
are cheaper are better than the more expensive tools, the tools backed
by a big company (i.e., Microsoft) are better than those not backed by
a big company (i.e., Perl), and so on. I once had the experience of a
manager giving thumbs down on a Linux server because he didn't know
it, and I couldn't argue with the logic that a tool that you know how
to use is 'better' than a tool you don't know how to use.

Perl is very good for some jobs, passable for others, and horrible for
other jobs. If Perl is the 'best' tool for a particular job, you need
to make the case. If you can't make the case, use whatever other tool
you have.

As far as I know, an ordinary user can install Perl and run Perl
scripts without the permission or intervention of the administrative
user. If you are dealing with some kind of firewall, that raises
different issues. If push comes to shove, you can always grab the
sources and compile it. I assume that your sysadmin doesn't have a
problem with C?

CC

 

[P B]

I'd like to install ActivePerl on a Windows XP machine...
[snip]

You have limited access rights, and Perl will run with your rights.
Hence it doesn't provide you with any magic.

That's just the answer I was looking for. Thanks, that will do it.

If your admins don't get it, they shouldn't admin computers in the
first place.

They aren't technically admins (only in the sense that they're in charge
of the computers and network, in fact that is one of their minor
duties.) The organization in question is not an IT shop at all, but
rather a (very) small community-based non-profit organization. They're
just erring on the side of caution. (They even require a password to
access the web via Internet Explorer on this special use workstation I
want to install Perl on.) I realize that their caution is probably born
primarily of ignorance, but at least they know enough to be cautious.
In any case, armed with your concise response, I can enlighten them and
they will assuredly indulge my desire to install Perl.

 

[P B]

I'd like to install ActivePerl on a Windows XP machine ...
[snip]

You "sell" the installation of Perl by tying it to a business need,
show it's value and how Perl allows you to meet the business need.

Yeah, I got that much from `perlfaq -q convince' but I have already
successfully shown these people how Perl effectively meets a business
need. They agree, but they are still reserved when it comes to
installing things they're not familiar with. It's my job (in this case)
to make them familiar with the security implications of a Perl
installation.

Regards,

PB

 

[P B]

IMNSHO that's quite an over the top statement.

Agreed. See my followup upthread. While I (sort of) agree with Dave in
principle, we're talking about people who are simply not familiar with
Perl--or, for that matter, any sort of language or runtime--at all. I've
already said it elsewhere: they're just erring on the side of caution.
As soon as I'm able to allay their doubts and fears, they'll be fine
with it.

 

[Ted Zlatanov]

PB> Also, the script that I'd like to run if I do get Perl installed uses
PB> WWW::Mechanize. Are there any links, resources, opinions, or first-hand
PB> experiences as to the security implications of this particular module?

I have not heard of any issues with WWW::Mechanize. It's stable,
reliable, and does only the operations you ask for (except for redirects
IIRC).

Ted

 

[nntpman68]

Hello,

I'd like to install ActivePerl on a Windows XP machine specifically to
run a particular script. The "problem" is that the admins in charge of
the PC are very cautious about what is installed and the security
implications of everything (as they should be).

Perhaps you could try to explain following:

Perl is 'just another interpreting language on your PC' and doesn't have
any specific security implications.

If they wanted to be safe, they had to forbid the execution of any
executable / script / macro not installed by them.

The damage you can do is done by the script you write and (rather)
independent of the language you implemented it in. (exceptions: the
script's runtime environment is a sandboxed or has other special
security features)


If you don't write servers and if you don't execute / eval anything
downloaded from unknown / external net works you're rather safe.




N

 

[Tad J McClellan]

I'd like to install ActivePerl on a Windows XP machine ...
[snip]

You "sell" the installation of Perl by tying it to a business need,
show it's value and how Perl allows you to meet the business need.

Yeah, I got that much from `perlfaq -q convince' but I have already
successfully shown these people how Perl effectively meets a business
need. They agree, but they are still reserved when it comes to
installing things they're not familiar with. It's my job (in this case)
to make them familiar with the security implications of a Perl
installation.

The proper place for fear is regarding the programs written in
Perl, not the installation of perl.

The probability of providing a "vector" in a Perl program is,
at least, thousands of times greater than the probability of
the perl program providing a vector.

Hopefully they don't know this much, or they'd really freak out... ;-)

 

[Ted Zlatanov]

n> If you don't write servers and if you don't execute / eval anything
n> downloaded from unknown / external net works you're rather safe.

I've often mentioned here and elsewhere that treating configurations as
code is a sure way to subvert security. Configuration should only be
logical data, not code to be executed, or else you end up with an easy
attack vector as soon as the program's configuration can be modified.

Specifically, programs should use any combination of YAML, JSON,
AppConfig, XML, and Getopt (as fits the purpose and environment). None
of those are as easy as a simple do("file.conf") but they are much more
robust.

Ted

 

[Dave Everson]

OK -- maybe a little. But I would not care to work in a place that won't
allow me to install recognized useful tools on my system. It is certainly
management's call as to what makes it into production environments but
developers should rightly be able to manage their own environments. In some
shops you can't install VI. Those aren't serious development organizations
and I would stay away.

 

[John Bokma]

OK -- maybe a little. But I would not care to work in a place that
won't allow me to install recognized useful tools on my system. It is
certainly management's call as to what makes it into production
environments but developers should rightly be able to manage their own
environments.

It was not clear to me if the OP was a developer.

As a freelancer I have been working on locations a few times (in the
beginning), and there was often a policy in place for installing new
software. It was not forbidden, but you had to motivate it.

In some shops you can't install VI. Those aren't
serious development organizations and I would stay away.

I can't see why. Over the years I have learned to be flexible.

 

[Sherm Pendley]

In some
shops you can't install VI. Those aren't serious development organizations
and I would stay away.

Some developers believe that they can't possibly write a single line
of code without their favorite editor or IDE. Those aren't serious
developers and I would stay away.

sherm--

 

[Jürgen Exner]

Some developers believe that they can't possibly write a single line
of code without their favorite editor or IDE. Those aren't serious
developers and I would stay away.

Well, there is certainly a big difference in ease and convenience
(important to the developer) as well as productivity (should be
important to the employer) when using something very basic like ed,
edlin, or even Notepad compared to an editor with all the bells and
whistles like syntax highlighting, automated indentation, command
completion, ...

Once you got a sophisticated editor then indeed it shouldn't matter that
much which one you are using.

jue

 

[Willem]

Sherm Pendley wrote:
)> In some
)> shops you can't install VI. Those aren't serious development organizations
)> and I would stay away.
)
) Some developers believe that they can't possibly write a single line
) of code without their favorite editor or IDE. Those aren't serious
) developers and I would stay away.

Some managers believe that the opinions of a developer, on issues such as
the correlation between editor familiarity and productivity, should not be
taken seriously. Those aren't serious managers and I would stay away.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[John Bokma]

Sherm Pendley wrote:
)> In some
)> shops you can't install VI. Those aren't serious development
organizations )> and I would stay away.
)
) Some developers believe that they can't possibly write a single line
) of code without their favorite editor or IDE. Those aren't serious
) developers and I would stay away.

Some managers believe that the opinions of a developer, on issues such
as the correlation between editor familiarity and productivity, should
not be taken seriously.

Wouldn't amaze me if those managers had in many cases a point. Sorry about
that news, it's probably not what you want to hear :-D

For the record, I am a freelance developer, and have learned a long time
ago that productivity is sooner limited by that gray stuff between the
ears than anything else. Probably because I had so often to make do what
was available.

I would have no problem with coding in Notepad. Of course I would miss
some things (and probably would write some small Perl scripts to fix
that), but most of my coding is typing out stuff. Thinking happens (here)
on paper .

 

[John Bokma]

Some developers believe that they can't possibly write a single line
of code without their favorite editor or IDE. Those aren't serious
developers and I would stay away.

Amen to that . I do most my coding in TextPad, and several years back I
suddenly had to use vim. After a day or 2 I was used to it (I had used
vi/vim in the past but not that excessive).

Same with version control. I am used to subversion now, but that's just
because I like TortoiseSVN a lot. Doesn't mean that I suddenly would be
crippled if I have to use svn on the cli. The ideas are the same.

And if I miss something, I code it; I am a programmer .