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

On Wed, 03 Sep 2008 10:39:16 -0400 P B <newsposter625@gmail.com.invalid> wrote:

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

P B wrote:
> 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

P B <newsposter625@gmail.com.invalid> wrote:
> On 2008-09-03, l v <veatchla@yahoo.com> wrote:
>> P B wrote:
>>> 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... ;-)


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

On Thu, 04 Sep 2008 02:02:56 +0200 nntpman68 <news1234@free.fr> wrote:

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

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.

--
Dave Everson

"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> wrote:

> 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.

--
John http://johnbokma.com/ - Hacking & Hiking in Mexico

Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-ex...or-a-gift.html

"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:

> 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--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

Sherm Pendley <spamtrap@dot-app.org> wrote:
>"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>> 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.

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

Sherm Pendley wrote:
) "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
)> 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

In article <m1d4jicysc.fsf@dot-app.org>,
Sherm Pendley <spamtrap@dot-app.org> wrote:

> "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>
> > 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--

In contrast, a friend just "escaped" from Agilent a while back. He came
away with some very interesting "prejudices" about development
environments. One he holds as a hard fast rule--he'll ask in an
interview what version control software they use. If it Clearcase,
he'll cut the interview short, thank the interviewer and leave as
quickly as possible. From my friend's perspective, any company that
uses "Clearcurse" is taking the tool selection out of the developer's
hands where it belongs. Clearcase sells well to management but anyone
who's tried to use it would immediately dismiss it as unusable.

I asked him what the main issues were as I've had clients who've had no
problems with Clearcase and didn't see why he was so vehement about it.
Before his small company was acquired by Agilent, they used CVS. It
worked OK and you could check out stuff from home and work over a DSL
line without a problem. "Clearcurse" took 10-30 minutes to check out a
single file over his DSL line. Other developers on the team have lost
lots of stuff to this beast and it was universally reviled. But it was
the Agilent standard and they had to use it.

I can see this as a possibility as it was likely developed for in-house
versioning with a resident Clearcase person on a release team all living
on a local LAN. The idea of remote developers probably wasn't on the
horizon in 1992. The Wikipedia article has a full list of issues.

--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]