Open source credit card processing in ruby


#1

Just recently I have the option to open source a credit card
processing application that is written in ruby using eventmachine.
This application processes cards directly to Vital. It basically
replaces an online payment gateway.

On one hand I’d love to open source it, but on the other I’m hesitant
because of the potential for abuse or misuse given the growing body of
security requirements that go along with credit card processing. I’m
also wondering if it would even get much use.

You have can have multiple copies of the application running that
share the same database (postgresql) for a certain level of fault
tolerance. The client protocol is netstrings over tcp/ssl.

Thoughts, comments?


#2

snacktime wrote:

You have can have multiple copies of the application running that
share the same database (postgresql) for a certain level of fault
tolerance. The client protocol is netstrings over tcp/ssl.

Thoughts, comments?

  1. Ask your attorney for legal advice.
  2. Ask your accountant for business advice.

I personally stay as far away from such things as I possibly can – I’ve
never written a business app in my life and don’t intend to start now.
:slight_smile: So I for one wouldn’t use it, whether it was open source or not. But
from a technical perspective, I don’t think open vs. closed source
really has any security impact. I don’t think it’s any easier or any
harder to attack or otherwise compromise open or closed source software.

For that matter, I don’t think there’s really any advantage to closed or
open source software in any of the dimensions we normally use to rate
software quality – ease of use, performance, reliability, security,
privacy, or even total cost of ownership! In my humble opinion, open
source software is all about freedom, learning, and community that
transcends organizational boundaries. The only weakness I see in open
source software is that it tends to be written more for programmers than
for other intelligent life forms. :slight_smile:


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.


#3

On 12/31/06, M. Edward (Ed) Borasky removed_email_address@domain.invalid wrote:

from a technical perspective, I don’t think open vs. closed source
really has any security impact. I don’t think it’s any easier or any
harder to attack or otherwise compromise open or closed source software.

Many security practitioners prefer open-source implementations because
it’s
easier to audit them. I have to ship security-sensitive code all the
time,
and my company’s large-company customers have always preferred that
everything we ship be on open-source.


#4

On 12/31/06, Francis C. removed_email_address@domain.invalid wrote:

and my company’s large-company customers have always preferred that
everything we ship be on open-source.

I’m mainly concerned about people modifying the source. Even though
it’s open source, it’s also certified and any changes that effect
messages sent to Vital require re-certification. There is also the
danger that Vital could at any time refuse to certify open source
implementations. If someone modifies the code and starts sending in
corrupt batches or causes other problems, that could happen rather
quickly.

Another option would be to make it free but not open source. The
source could still be provided for review to those that need it, but
would require signing a simple contract to not release the source, and
not to modify it unless you were a Vital developer, which only costs
$100. But with those restrictions I doubt many people would even use
the software. It has a limited market to begin with, even though
there is nothing out there like it that isn’t fairly expensive.


#5

On Dec 31, 2006, at 4:07 PM, snacktime wrote:

Another option would be to make it free but not open source. The
source could still be provided for review to those that need it, but
would require signing a simple contract to not release the source, and
not to modify it unless you were a Vital developer, which only costs
$100. But with those restrictions I doubt many people would even use
the software. It has a limited market to begin with, even though
there is nothing out there like it that isn’t fairly expensive.

I’d love to see it just so I could see a (hopefully) good example
using eventmachine and a home-grown protocol using netstrings.

If you don’t opensource it, put me on the list of people who’d like
to see the source code.

Happy New Year!

cr


#6

On Dec 31, 2006, at 5:55 PM, Matt L. wrote:

$100. But with those restrictions I doubt many people would even
You may want to take a look at CCVS by HKS, which was purchased by
Red Hat.

Actually, I don’t really care about what it does (credit card
verification). I just want to see some running code using netstrings
and eventmachine.

Does CCVS use it? I searched for it and got a few hits but didn’t see
any obvious links that lead to its source code.

cr


#7

On Mon, 1 Jan 2007 removed_email_address@domain.invalid wrote:

I’d love to see it just so I could see a (hopefully) good example using
eventmachine and a home-grown protocol using netstrings.

If you don’t opensource it, put me on the list of people who’d like to see
the source code.

You may want to take a look at CCVS by HKS, which was purchased by Red
Hat.

– Matt
It’s not what I know that counts.
It’s what I can remember in time to use.


#8

On 12/31/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

I’d love to see it just so I could see a (hopefully) good example
using eventmachine and a home-grown protocol using netstrings.

There is some netstrings sample code in the eventmachine repository
somewhere, that’s where I got the idea from. I’d never really looked
at it before, and when I did I liked it. It’s great for simple line
oriented tcp protocols.

Chris


#9

Does CCVS use it? I searched for it and got a few hits but didn’t see
any obvious links that lead to its source code.

CCVS was dead a long time ago, and was never open source. They had
open source client libraries is all, which is nothing special.


#10

On 1/1/07, snacktime removed_email_address@domain.invalid wrote:

I’d love to see it just so I could see a (hopefully) good example
using eventmachine and a home-grown protocol using netstrings.

There is some netstrings sample code in the eventmachine repository
somewhere, that’s where I got the idea from. I’d never really looked
at it before, and when I did I liked it. It’s great for simple line
oriented tcp protocols.

I realize this is offtopic but are any of you guys interested in adding
an
industrial-strength netstrings implementation to the EM package?


#11

On Jan 2, 2007, at 12:02 AM, Francis C. wrote:

I realize this is offtopic but are any of you guys interested in
adding an
industrial-strength netstrings implementation to the EM package?

Define industrial strength. :slight_smile:

I have some interest in this area. Feel free to contact me off-list.

cr


#12

On 1/1/07, snacktime removed_email_address@domain.invalid wrote:

there is nothing out there like it that isn’t fairly expensive.

I’d love to see it just so I could see a (hopefully) good example
using eventmachine and a home-grown protocol using netstrings.

There is some netstrings sample code in the eventmachine repository
somewhere, that’s where I got the idea from. I’d never really looked
at it before, and when I did I liked it. It’s great for simple line
oriented tcp protocols.

You might be interested in this article, published in this month’s CACM.
http://portal.acm.org/citation.cfm?id=1188913.1188921&coll=ACM&dl=ACM&idx=1188913&part=periodical&WantType=periodical&title=Communications%20of%20the%20ACM&CFID=10300099&CFTOKEN=82686562


#13

On 1/2/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

somewhere, that’s where I got the idea from. I’d never really looked

cr

Well, I’m assuming from the little that I know that netstrings is
something
like BER: you have encodings and decodings for things that can become
marshalled objects. I’d like to simplify the process of writing clients
and
servers that are based purely on netstrings (and then we can add hybrids
later). So I’m imagining a subclass of EventMachine::Connection in which
the
receive_data method can read netstrings, and when it detects one, it
calls a
method (#received_netstring ?) that can be subclassed by the user. On
the
client side, you’d want to be able to say #send_netstring(*args), and it
would just do the right thing with a variety of inputs. Does this make
any
sense?