secure internet Perl programming for banking

[kj]

I'm looking for a book on secure internet programming for
banking/financial applications, preferably for Perl programmers.
Supposedly there's a lot of stuff on this for Java, but I'd prefer
to avoid Java if possible (nothing against Java; I'm just far more
comfortable and proficient with Perl).

Is there a Perl mailing list devoted to secure Internet programming?

TIA,

kj

 

[Anno Siegel]

I'm looking for a book on secure internet programming for
banking/financial applications, preferably for Perl programmers.
Supposedly there's a lot of stuff on this for Java, but I'd prefer
to avoid Java if possible (nothing against Java; I'm just far more
comfortable and proficient with Perl).

Is there a Perl mailing list devoted to secure Internet programming?

I don't know, but the Perl Mailing List Database at http://lists.cpan.org/
will answer that. A mailing list seems like a good idea for a subject that
specialized.

Anno

 

[Malcolm Dew-Jones]

kj ([email protected]) wrote:



: I'm looking for a book on secure internet programming for
: banking/financial applications, preferably for Perl programmers.
: Supposedly there's a lot of stuff on this for Java, but I'd prefer
: to avoid Java if possible (nothing against Java; I'm just far more
: comfortable and proficient with Perl).

: Is there a Perl mailing list devoted to secure Internet programming?

No idea about a mailing list, but perl can use various SSL modules, and
that allows perl to directly communicate over a secure channel (if the
terminology is wrong then sorry).

For example, various credit card payment systems use HTTPS to receive the
requests from the web sites dong busines, and a perl cgi script on the web
server can send these requests using LWP after you install one of the SSL
modules.

 

[J Krugman]

kj ([email protected]) wrote:

: I'm looking for a book on secure internet programming for
: banking/financial applications, preferably for Perl programmers.
: Supposedly there's a lot of stuff on this for Java, but I'd prefer
: to avoid Java if possible (nothing against Java; I'm just far more
: comfortable and proficient with Perl).

: Is there a Perl mailing list devoted to secure Internet programming?

No idea about a mailing list, but perl can use various SSL modules, and
that allows perl to directly communicate over a secure channel (if the
terminology is wrong then sorry).

This is not my area of expertise, but I can tell you that there's
a *lot* more to banking programming security than communicating
over SSL.

I don't know of anyone doing this kind of work in Perl. I'm not
sure exactly why Perl would be unsuitable, but AFAIK it's just not
used in this domain (internet programming for banking).

Does anyone know why?

jill

 

[L D Jones]

This is not my area of expertise, but I can tell you that there's
a *lot* more to banking programming security than communicating
over SSL.

I don't know of anyone doing this kind of work in Perl. I'm not
sure exactly why Perl would be unsuitable, but AFAIK it's just not
used in this domain (internet programming for banking).

Does anyone know why?

The conservative nature of banks makes them less likely to accept a
solution not based on software from a large vendor.

 

[Cyde Weys]

L D Jones wrote:

The conservative nature of banks makes them less likely to accept a
solution not based on software from a large vendor.

That makes total sense to me. Hell, I know that if banks weren't
conservative, I wouldn't give them my money I'm not saying that
their conservatism (is that a word?) in this case isn't unfounded, but
as an overall quality, it's a good thing.

 

[Anno Siegel]

J Krugman wrote:

The conservative nature of banks makes them less likely to accept a
solution not based on software from a large vendor.

Translation: There's no-one to sue when something breaks.

Anno

 

[J Krugman]

Translation: There's no-one to sue when something breaks.

How 'bout the programmers?

jill

 

[Tad McClellan]

How 'bout the programmers?

You can't get blood from a turnip.

 

[Matt Garrish]

Translation: There's no-one to sue when something breaks.

Another translation is pointy-haired managers with no technical knowledge
are dupes for support plans, and any company that can provide one is
certainly more trustworthy than one's own employees. Which also translates
to: it's easy to cover one's ass by blaming another company for shoddy work
than it is to explain why your people came up with shoddy work.

Matt

 

[J Krugman]

The conservative nature of banks makes them less likely to accept a
solution not based on software from a large vendor.

The implication here is that "large vendor" implies "no Perl". It
is not obvious to me why a large vendor, even one wedded to the
"traditional" propietary software model, couldn't develop its
software in Perl. As far as I can tell, Perl's license doesn't
prohibit writing proprietary software in Perl.

If all the comments around the issues of conservatism, liability,
and support really reflect reality, then they suggest to me that
for the foreseeable future the proprietary software model will
continue to dominate the more lucrative segments of the software
market, and the FSF model is doomed to the relatively less lucrative
segments of the market.

jill

 

[Malcolm Dew-Jones]

Anno Siegel ([email protected]) wrote:
: > J Krugman wrote:

: > > I don't know of anyone doing this kind of work in Perl. I'm not
: > > sure exactly why Perl would be unsuitable, but AFAIK it's just not
: > > used in this domain (internet programming for banking).
: > >
: > > Does anyone know why?
: >
: > The conservative nature of banks makes them less likely to accept a
: > solution not based on software from a large vendor.

: Translation: There's no-one to sue when something breaks.

Do you think anyone every sues M$ then their software breaks?

 

[Peter Scott]

This is not my area of expertise, but I can tell you that there's
a *lot* more to banking programming security than communicating
over SSL.

I don't know of anyone doing this kind of work in Perl. I'm not
sure exactly why Perl would be unsuitable, but AFAIK it's just not
used in this domain (internet programming for banking).

I don't know whether the applications are/were networked, but I know
that Perl is/was used for important banking applications. At an
OSCON a couple of years ago Tim O'Reilly said that three major
Fortune 500 companies (banks IIRC) had told him that they considered Perl
to be their "secret weapon", but forbade him from publicizing their
names.

A large brokerage house was running huge sums of money through
programs using Parse::RecDescent as recently as 2001 and I have no
reason to believe they have stopped.

 

[James]

I don't know of any books which cover this topic specifically... But I can
state that there is at least one payment gateway out there that uses SSL
secured servers, SQL databases & Perl as their primary design solution for a
online payment processing & connectivity to the banking system.

Check out www.plugnpay.com

 

[at]

The conservative nature of banks makes them less likely to accept a
solution not based on software from a large vendor.

Speaking as one who has devoted most of my 25 year career designing,
developing, deploying and supporting full financial solutions for
financial institutions, I've been moving steadily into the open
solution for the past 14 years. I use a lot of perl as our home
banking and internet lending suites are completely written in perl and
more and more of the supporting modules are being written in perl. In
fact, I just completed a facility to obtain credit reports from one of
the major bureaus via a perl program over ssl web access (with NO user
involvement). Works great and works FAST! And another that
automatically access index rates from the Federal Reserve site for use
in Adjustable Rate Mortages... completely written in perl.

However, as good as this is, the Feds are seeming intentionally trying
to BREAK both the small vendors (read: < 100 staff) and especially
solutions written with GPL governed languages. They actually seem to
favor (actually recommend) M$ solutions to my clients just coming
short of insisting that they move away from any vendor using GNU
products.

So much for the American way!

Any banks/credit unions want to purchase a COMPLETE banking suite
relatively cheap???