Slashdot Mirror
Red Hat buys Hell's Kitchen Systems for $80M
Anonymous Coward writes "Yahoo reports Red Hat is buying this e-commerce company. Their product (credit card verification system) appears to be closed-sourced." I called Melissa London at Red Hat to find out the scoop; it's all open source above the API. Below that, the verification system makes use of the financial institution's proprietary protocols, which are made available to HKS under NDA. It's not perfect, but until the banks get clueful, it's the best we can hope for.
The only encryption that has been proved secure is the magical 'One time pad', but it suffers from the problems associated with key distribution, making it impractical for most applications.
I agree that most of the problems are in the impelentation - you only have to follow SSH on BugTraq to know that!
But anyway, arn't most financial institutions still using plain 'ld DES - publicly known and with a massive key of 56 bits? Or am I living in the past?
I'd say reverse engineer it. That way Red Hat just spent $80M on nothing, as what they paid for would instantly become decertified.
Oh well, huh?
I don't think banks can be expected to embrace open source anytime soon. They are slow monolithic beasts. How many are still using cobol? Dumbass, information systems for financial services live up to standards of performance and availability that most people reading this have no concept of.
Uh, I think you are referring to the NEC cash mashines. You probably remember that from a previous slashdot discussion. Nice try, though.
Then you've got us smaller critters who buy what's out there. And guess what? If there's no open source software out there, you can boycott until you're blue in the face, but that isn't going to make the software exist. Financial software isn't sexy. It's tedious, number-crunching junk. You don't catch the open source crowd writing it in their basement for fun.
Banks (smaller ones, anyway) move fast, actually. It's a cutthroat business. But we have to interface to the Fed (FHA, HUD, GNMA, FNMA, a whole alphabet soup) and guess what? We're still sending out 9-track tapes. We sure as heck don't use those internally, and we don't use them (or physical media at all, if we can help it) when interchanging with other institutions.
If you want to accomplish something, don't whine at the banks. Tell the Fed. Call up the OTS, the FFIEC, the FDIC, all those guys. Try to convince them that open source software is secure, because even if it's available, we can't use it if they don't trust it.
Best of luck.
The Hat says, he's going to roll the stocks around, shining the kitchen real nice, turn it sideways, and stick it straight up to the sink hole of Hell!
:)
Seriously, what the hell does this kitchen sink company do anyways? Maybe it is doing bloatware with everything including a kitchen sink in it?
Is it because it used sell software to chefs and restraurants? Or is it because the company had made bloatware with kitchen sink in it?
Meaning, simply, that the machine was coming to it's knees after a few days simply because of a poor way to store transactions. This could have been cut down to a few hits to the filesystem, had a schema as simple as naming the file after the transaction ID been implemented.
Word is that current versions of CCVS actually do this, since earlier in major version 3. The system load for the CCVS daemons have reduced enormously to where they're not a factor (except they eat file descriptors like there was no tomorrow - BFD).
Each BSD system sold in a market where Red Hat is a player is loss of revenue for the company. I can see Red Hat releasing versions of closed-source software they've purchased and are now developing with their own (the venture capitalists', really) money as readily as Microsoft porting SQL Server or Office to Linux.
free open source
merchant software
with reverse engineered specs
ftp://ftp.psychosis.com/openccvs/
And no, linux users don't constitute a significant constituency to force the issue through boycotts.
The banks could laugh off your threat, but you'd succesfully destroy HKS, which would leave only the closed source players behind.
How your dumbass suggestion got moderated up is beyond me.
"Bred" is one of the largest french bank and they use Squid and Apache (without my french translation, booh !) to give customers access to their acount thru the internet. -Jedi.
at ALL times, b/c you're in for a roller coaster ride of hellacious proportions. One thing that MS has over RH at least for the unfoggy future is stability. Sure MS may lose a few billion in revenue one quarter or another (ugh, have we really gotten to the point where 9 zeroes is blase?) and their stock drops a few dozen points here and there, but in the long run, MS is a blue-chipper through and through. Like GE or Coca-Cola. Seriously, Coca-Cola could ship a few hundred truckloads of Diet Coke filled to the brim with rat feces, cyanide, arsenic, bleach, and heroine; and Jack Welch of GE could take an American flag and riddle it with cigar burns and defocating on it and then flicking a booger on the Vietnam Memorial before smoking crack with Marion Berry behind the Washington Monument, and you would nary see a *DING* in their stock price . Same with MS. Their OS and bread and butter Office suite is bugged all to hell and crashes on everything it touches, but damn is that P/E ratio sweet as rock candy. I'm not knocking you for cashing out, but you better not check RHs performance religiously, lest you feel queasy every other day. Long term, no problemo, but don't expect the miraculous performance forever.
Forward-looking statements in this press release are made pursuant to the safe harbor provisions of Section 21E of the Securities Exchange Act of 1934. Investors are cautioned that statements in this press release that are not strictly historical statements, including, without limitation, statements regarding the combined operations of the two companies, management's plans and objectives for future operations, and management's assessment of market factors, constitute forward-looking statements which involve risks and uncertainties. These risks and uncertainties include, without limitation, risks associated with the difficulty of integrating the two companies, the potential failure to achieve the beneficial synergies expected to result from the merger, Red Hat's dependence upon an open source business model, reliance upon independent third-party Linux developers, management of growth, reliance upon strategic relationships, expansion of Red Hat's business focus and operations, the possibility of undetected software errors, the enforceability of the GNU General Public License and other licenses under which Red Hat's products are developed and licensed, the scarcity of Linux-based applications, the risks of economic downturns generally, and in Red Hat's industry specifically, the risks associated with competition and competitive pricing pressures, the viability of the Internet, year 2000 compliance efforts of Red Hat and of third parties on which Red Hat depends, and other risks detailed in Red Hat's filings with the Securities and Exchange Commission, copies of which may be accessed through the SEC's web site at http://www.sec.gov.
Banks now mostly use OS/2 to run a 3270 terminal emulator, but sometime they use Windows because it doesn't matter.
They are for the most part still using DOS for most applications. Some of the more progressive banks are using OS/2.
$1500 is NOTHING in the grand scheme of things,
especially considering you are paying for software,
not a service (ie. no per-transaction fee). For
any significant business, this is a drop in the
bucket. If you need something cheaper, you can
save yourself time and money by going with one
of the many shareware-oriented online registration
services (like www.regnow.com)
Again, evidence that what people are really
interested in is free beer. Thanks GNU!
Buy the lzw patent, do usall a favour
Got any balls?
Hmm. I seem to have a copy of the Novus (Discover) protocol here with me. It's really pretty simple stuff. I'm sure someone could reverse engineer it very easily (once they had a POS system to test on). To use it, you have to join Novus' network (ie. pay money). Once you've done that, they have no way of knowing if you're using their real client or an open-source version. If someone outside the US wanted to make such a program for Linux, the Novus documentation might accidently end up in their in-box.
Open sourcing the protocols they use could very easily hurt them, not help them. They have done an excellent job thus far. Besides how would open sourcing the protocols help us? It wouldn't make this kind of software availible to the average joe
The best security software tend to be the ones that get the most peer review. The credit card industry still has a lot to learn and they could learn alot by following the examples of such works as Secure Remote Password. The problem is that credit card verification is still "secured" via obsecurity of method. The use of a closed method to maintain the obsecurity doesn't keep someone who is willing to put forth enough resources from discovering the method used. If anything, it only limits the amount of peer review and the ability of peers to provide fixes. But if you think about the goals of credit card verification it is exactly the same goals that SRP was written to solve. Credit card verification protocols should authenticate knowledge of a certain piece of information without compromising the obsecurity of the information and the protocol should be univerially usable even in areas of the world which might not allow strong data encryption. But while credit card protocols tend to use "obsecurity" to keep the information secret, SRP uses an open zero knowledge method of verification.
what exactly is outrageous about the pricing?
This is not some consumer product with tens
of thousands of sales. this is not an unusual
price for a product like this. Unfortunately,
your view is apparently distorted by GNU and
open source, where nothing is expected to cost
over $100 (or something silly like that).
And where does it say you HAVE to renew the support
contract!?
You lucky dog! *My* bank just moved to abacuses.
You're absolutely correct, you are an idiot to me
I worked at Deutschebank and didn't see hide nor hair of OS/2. It was NT on the client and Solaris on the server.
to test it on a Linux POS system gene@viewtouch.com http://www.viewtouch.com
Even with only the binary program available, it is quite possible to dissassemble it and figure out what it does. It is only a matter of motivation and basic assembler knowledge. More people than you think, have this knowledge.
The motivation part should be obvious when we are talking about a money transaction system.
Piggy-back on the CVS at porn sites. Find one that offers a 7-day trial or look for a free Adult Verification services like Sex Key or whateve. Type in the card info and see if it gets accepted or rejected.
Most of those sites are fussy as hell so if the porn comes through, you can do ahead and fill out the paperwork.
Of course, you should probably cancel before the free trial ends so your customer doesn't end up with $20 to "Internet Entertainment, Inc".
I know some people on eBay who do this before filling out those old-fashioned carbon-paper, only to find out the card is bogus three weeks later.
--- The entire world runs on AC, baby! ---
Hopefully RedHat will revise the outragous pricing and the 1 year support that you HAVE to renew each year.
Hmmph, more Redhat complaining. Why don't you run a *real* OS like UltraFlopBSD rev. 18.4.6 ..? Rouge_Chapeau is just too mainstream for me. With UltraFlopBSD you can see the full source. All 5250 megs of it. :P
There have been a few comments concerning the security for the protocols used in CCVS. The First Data protocol used in the CCVS provides absolutely NO security what so ever. Why FDC tries to hide them under NDA is a mystery and joke. They are old as hell and meant to be use on private network dialup. Anyone trying to scam money into a merchant account would caught damn fast so hiding the specs provides no advantage. This protocol has already been successfully reverse engineered with the OpenCCVS project which also includes documentation on the protocol. Check out ftp://ftp.psychosis.com/openccvs/ As it stands now this package works! It needs a bit more work to fix 2 import credit functions which dont seem to work correctly and make it 100% bug free since we are talking money here. Its a bit fussy on certain merchant accounts for unknown reasons. I encourage everyone to check this out and help bring it to the next level. The core is there and what it really needs is API extensions and MORE clearing house protocols. A solid merchant account library with the multiple API's would provide a solid base for full fledged open source credit systems and applications. (sql datasources,gnome/kde/win32 apps etc etc) The HKS software is fantanstic but HKS and the rest of the credit industry (software and clearing houses) have shown they are crooks. Examine the OpenCCVS software and look at the simple function they performs and decide for your self.
Lay off the Ayn Rand, already, fool.
I called Rob Malda at Andover to find out the scoop; it's all open source above the bullshit. Below that, the posting system makes use of the commercial institution's proprietary code, which is made available to noone under no NDA whatsoever. It's not perfect, but until Andover gets clueful, it's the best we can hope for.
HKS's software is expensive and hopefully this will lower the cost a bit. CCVS is needed by everyone doing e-commerce these days. go redhat! scott@x13.com
Does this arrangement allow the other distros
to include the same software and have it work
or not?
If a system's security relies on its secrecy, it is far from secure. You'd have to trust that at no time had the wrong set of eyes ever seen under the hood.
uh no. Why single out HKS? Just don't do ANY CC transactions, ever, with any bank.
-
- Why is the ninja... so deadly?
Okay, review time. "Security through obscurity" refers to keeping the details of how a system functions out of the hands of the masses, for fear that someone will figure out how to exploit some flaw in the system. This has been shown repeatedly to be unsafe, as people who are interested have a nasty habit of finding those vulnerabilities anyway. (It also tends to complicate and frustrate efforts to improve security.)
SSH and shadow passwords do not rely on security through obscurity. They do rely on hiding information (hence "cryptography"), but the process by which they generate and hide said information is an open book. Not the same thing.
Just because Redhat Linux is GPL doesn't mean that software running on top of it has to be.
---
I know for a fact that Deutchebank (probably a typo since I'm not German :) uses OS/2
---
This bit of news from RedHat seems even more funny considering that I received a call from one of their customer relations/billing represenatives today. She was calling to inform me that, "due to a problem with their credit card transaction processing vendor," some customers who made purchases on their website had been billed twice.
......"
:)
I was impressed that they did take the time to call and inform me that the second charge would be removed from my card.
What burned me about making that online purchase was that I received a offer for a free "RedHat Cap" (if I purchased v6.2 online) about a week later.
So when she asked if I had any other questions, I asked for the Hat. I said, "I've been a loyal customer since version 2.1 and
I should get the Hat sometime next week.
Glad to hear about this one. CCVS is seriously cool. I just hope they don't abandon (and stop selling) their FreeBSD port of the software!
Absolutely right with all your comments. I figure that in 10 years or so I'll be happy to have bought my Red Hat stock.
If I were to sell it today, I'd lose a big chunk. You don't lose until you sell, right? In 10 years I won't care about the temporary price dip after I bought.
If tits were wings it'd be flying around.
If Red Hat lowers the (certainly) obscene price of this package, and starts bundling this CC validation code with their commercial distro bundling, I wouldn't be surprised to see it reverse-engineered within a year from now.
Right now, the only reason that the CC validation code hasn't been reverse-engineered is probably because too few people have the code to play with, or that few people even know where to get it. For example, this is the first time I've ever heard of a CC validation code being available for Linux in the first place.
Red Hat will probably burn this 'ware onto the commercial version of their distro, which should be sufficient to flood the market with umpteen copies of it.
Let's put it this way: I'd be very much disappointed even this doesn't get reverse-engineered within a year.
--
I *gasp* DON'T want my bank to give away source code to their software either!... and I know this violates the GPL propaganda line. Tough. The fact is security through obscurity WORKS, otherwise what would be the point of SSH or /etc/shadow??
It could indeed be security through obscurity, but I havn't lost faith in RedHat yet, and probably won't over something like this. We're only getting a small article and a four line blurb on Slashdot, maybe its security thourgh really good code and obscurity. Eh, who knows.
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
jdube is who
Wouldn't an open source credit card verification system be a Bad Thing(tm)? I would assume that this would make it easier to engineer the ablility to compromise the transaction. I know that security through obscurity is a bad policy by nature, but in these types of things, is it not required?
Run. I like water. Push My rutabaga.
The OS it is running on is open sourced. :-)
c7five
yeah, no shit.
who else has stopped giving a crap about what Micro^H^H^H^H^HRed Hat is doing anymore?
Still, the data we're talking about is different.
In the "personal privacy" corner, we've got my credit card numbers, my social security number, *specific actual data* about me. Private stuff.
In the "proprietary corporate information" corner, we've got the methods the data is stored, transfered, used, etc.. *NOT* the data itself. The data itself, of course, is private. The methods can be private too, for all i care, except when the data is info about me, that i am supposed to trust them with.
That sounds like quite a useless statement to me. Hey, Microsoft Office is "Open Source above the API", with the API being VBA and nothing there above it. Does anyone know if there is anything in HKS's product that's actually open-sourced?
Youse aint' from around here, is you? Hell's Kitchen is a neighborhood in da city.
-russ
Don't piss off The Angry Economist
I dislike all those who dislike RedHat and even more specifically rpm!
So Sir go to Hell with all your hate and paranoia!
Now, do you say the same thing about Debian going commercial?
Kill Microsoft? No! Just hire their GUI guys!
I do care about what RedHat does and I don't own stock in it!
It's simply the best overall distro out there!
Go RedHat!
Kill Microsoft? No! Just hire their GUI guys!
no it wouldnt..the software you use would not be certified. only certified software is allowed to be *sold*..which is different from open sourcing a clone of it for your private pleasure.
have you ever used COBOL? ... *shudder*
Unix is elegantly designed (well mostly, ish, sort of, perhaps), COBOL is just hideous.
--
Hi.. I was wondering if anyone had an opinion on First Data Resources, a credit card processing/holding company.
How we know is more important than what we know.
Hmm. I might dispute that slightly - Redhat knows it is in it's best interest to keep in good standing with the OSS community, who are the source of the Linux software it is selling, and takes pains to be seen to "do the right thing".
Then again, I suspect that what Macchiavelli said of States can be equally applied to corporations. They are not "moral" or "principled" in the sense that a man can be.
no, but they are led by a board of directors that is small enough to reflect the personalities of it's members - governments just have too many people with too many agendas to do similarly.
--
-=DaveHowe=-
ummm... I really don't know that much about complex application design, but isn't open sourcing everything "above API" kind of like calling happy hour a soup kitchen?
Vote Technocratic! Government by killer robots!
Whats wrong with that? As long as it works for them. Remember the people working at the bank arn't usually big computer users. they know what they need to know. Changing systems all the time to the "newest" and "best" would mean having to train the whole staff over, insteed they are saving money and leaving well enough alone
Many people tout open sourcing as the ultimate cure to all security woes. And yet, as we know, open source products still have security problems, perhaps as many as closed source products. Sure, sure, there are some very secure, very well tested open-source programs, but I'm sure the same applies to closed source.
Just open-sourcing something will not make it inherently more secure. I don't know how many people would actually be interested in working with this code, but I'd be willing to bet it's a lot less than those who want to work on, say, GNOME, or ProFTPd. After all, more people want to use those programs.
Yes, this has been said before, but it needed to be said again.
---
END OF LINE
How about this instead: Send them a clue. By email, by boycotts, by not buying HKS, etc
Yes, and I'm so sure that people that would boycott/email represent so many bank customers that they wouldn't be laughed at for boycotting a bank. What exactly is so wrong with banks at the current point in time that would require them to open source their software? You're an IT professional, and you "know" that the only good security is open security, do you think if security by obscurity was really that bad banks would use it? The banks aren't clueful of what? That "open source" is taking over the world? Let me know and I'll shut up.
I remember when HKS rented out floorspace from the non-profit where I was working. A good bunch of guys. They'd help us out alot since we were just a bunch of clueless hippies then (some might say I still am...)
Its also nice to see a tech firm that's NOT in New York or California making some $dough$. (Yay, Pittsburgh)
Just a note of congrats from one who's trying to make to to another who has.
Actually most all public key cryptography is based around the whole concept of security through obscurity. Think about it real hard. Think about the piece of information you need to hide to keep the system secure. The private key of course.
Consider how something like RSA public key crypto works...
* Find 2 very large primes, p and q.
* Find n=pq (the public modulous).
* Choose e, such that en and relatively prime to (p-1)(q-1).
* Compute d=e^-1 mod[(p1-)(q-1)] OR ed=1[mod (p-1)(q-1)].
* e is the public exponent and d is the private one.
* The public-key is (n,e), and the private key is (n,d).
* p and q should never be revealed, preferably destroyed
Note what you end up hiding here. Your obscuring certain numbers. Hence RSA ends up being security through obscurity.
Yes, you may say that the system is open, (which btw in the USA it really isn't...remember RSA Inc. still holds that patent) but the ideology behind it isn't much different that keeping the gory details of its functionality away from the masses.
I guess it comes down to different definitions of "security through obscurity".
I'd have to agree with you about all of us being hippocrits. Consider how many of us work so hard at secureing systems we administer. Do any of you remember when most anyone could login to a remote system, and you as the admin of that system didn't have worry about somebody doing something bad.
I remember reading something about RMS not giving himself remote access to his machines because they had to be secured and as a result since the systems weren't open for all to use and work on, why should he be allowed access to the same.
So many of us seem to forget the ideology that brought about the Free Software movement. A lot of people haven't heard the term "Free Software" but have heard "open source". We really need to be pushing harder for truly free software and systems, but unforutnately these systems need to be secured because society as a whole can not trust itself.
Its a sick, sad world isn't it folks.....
Red Hat + success == Good Thing(tm)
Here's my DeCSS mirror, where's yours?
You don't have to like their distribution, but there's no basis to comparing them to Microsoft. Domination of Open Source == domination of no one. They can't overcharge you, because the stuff is freely downloadable off the net. Since all their stuff is open, a program written for Red Hat will work on any distro. A business founded on Open Source has no leverage against consumers.
Here's my DeCSS mirror, where's yours?
As a satisfied customer of CCVS software I am curious what negative impact this purchase will have for me. It reminds me of when Microsoft bought the company that made the program that became Site Server. I distrust and dislike the RedHat path of becoming the M$ of the Linux community, and I dislike the path that many commercial "Linux" applications are following of supporting RPM and RedHat as well.
For the record BSD has a 4 CD set that has 4x more software that REDHAT bundles up. Personally it seems like your boss is a bit misinformed or thinks life will be easiler if everyone is assimilated. *grin* Me I run them all and I'll still pay for Compaq/Digital Tru64 UNIX. Still the best unix in my book so far.
IF you BUY the cheapest Hardware you'll GET the cheapest hardware and then some. Get Inspired!
Or, well, there is no contradiction in both encouraging privacy and freedom of information at the same time, even if it might sound that way right off the bat. "Freedom of information" does not mean "everyone should know everything about everyone and everything" "Freedom of information" is something that applies when privacy is not an issue. Like, I wouldn't want my bank to tell everyone exactly how much money I have, and where I buy stuff and the like. I would like them to tell everyone how they safeguard that secret of mine (ie, open their source). Basically, believing in freedom of information means belieaving that everyone should have access to all information, providing that everyone having access to this information does not violate the privacy of someone else in a non-trivial way.
Bjarke Roune
This is so Slashdottish, yet I'm compelled to comment. For everything BUT this software, "closed source=the keys to hell". But wait, Red Hat (can't do no wrong), which sells Linux (savior of the people), buys this closed source stuff, all of the sudden, its all kosher. I guess I shouldn't be so surprised at the hypocracy. After all this is /.
I can't speak for anyone else, but I had a very good experience with them.
PS, we'll sell for less than $80M :)
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
RPM, SRPM, and source tarball at:
http://www.blackholesun.com/occvs
Just a directory with files now, full web page to follow.
Dave Cinege doesn't work on this anymore, but we are fixing it up to use for our own site.
... In Hell(s kitchen) before the banks open source their software. We can threaten them with boycotts and rioting all we want, if they OS their systems, we're gonna see all the back doors and ways their screwing us out of out money, as well as letting some less than friendly coders find a way to crack the security from the front end. I think we'll see Bill Gates release the source for Win2k before any bank gives out their systems.
=======
There was never a genius without a tincture of madness.
Banks now mostly use OS/2
Actually, in the US, personal privacy is the same thing as proprietary corporate information. The purpose of incorporating a business is to create a legal entity distinct from any human. In the eyes of the law (at least theoretically) a corporation is entitled to pretty much the same rights (and is supposed to follow the same laws) as an individual.
Is it yet another triumph for the open source community, or is Redhat going the wrong way (i.e., the Microsoft way) ? I think it is a bit too early to judge.
Although many would see this as big company eating up smaller company, what they are doing is openning up market for Linux. More people will be able to use Linux as a solution, and this can only be a good thing.
- Etam
We're having a lot of new "direct" banks in Germany since the internet boom started (believe it or not: late 1998) and they seem to feel the need for more advanced systems that are able to quickly introduce new services, in order to stay On Top.
Since these rivals arose, our big & conservative banks seem suddenly beeing urged to use the same systems... mostly object-oriented, Smalltalk or C++ Clients, C++ Servers (occasionally Smalltalk/X) and CORBA for the communication (good for legacy systems integration).
I can Imagine just a handful of companys that could realize systems of this size, apparently this was the main reason to choose Smalltalk, since Smalltalk companies tend to have more experience in *big* object-oriented projects than the others (IMNSHO).
If they don't comply with our standards, let's go and boycott them. Since we're engineers, problem stating isn't just enough.
Not all updated systems were very modern though. Quite a few of the new systems wouldn't have looked out of place in the 70's.
It's not really a case of being "modern" though, it's more that they are still conservative (with a small C) and traditionalist - you don't stay in business over the long term by taking unnecessary risks, and that includes going with the latest trends for the sake of it.
As an example, Samba is quite often used within banks to integrate Sun workstations with NT, however Linux is frowned upon. The argument against Linux is the usual "no-one owns it, it's free, it's not to be trusted". Strangely this isn't applied to Samba - presumably because they need it!
Right, if the banks refuse to release source we have to reverse engineer the program or use it as closed source.
Reverse engineering doesn't necessarily help here. It's probably a breech of contract to use non-approved software to connect to the system (and it is THEIR system).
The systems used show signs of being quite old (1200 - 2400 baud with even parity for starters), and may not be robust enough to deal well with protocol errors.
I would like to see that fixed, but it may take a while for it to actually happen. I think it would be in their best interest to fix it as well before someone does reverse engineer the protocol and use it to attack them.
However, blame doesn't really come into it as much as one might think.
Blame was probably too strong a word. I can see your point, it would be awefully expensive to make the transition. It will have to happen one day anyway, but probably not quickly.
for speed: you have the source, fix it.
for size: you have the source, fix it.
for running something else underneath it: you have the source, build it.
one of the things i like about free software is that it really highlights the whiners from the doers...
US Citizen living abroad? Register to vote!
is up 41 dollars on the news. Amazing what a little press release can do.
Anyway, RedHat's agressiveness in finding more markets for themselves and therefore Linux is what prompted me to sell off my Microsoft and buy Red Hat stock with the money. It would be nice to see more of this sort of thing from the other Linux companies though. I want to see many large Linux companies besides Red Hat sharing the marketplace.
If tits were wings it'd be flying around.
"Big clueless industry with no will to innovate depends on closed-source security-through-obscurity to protect its service."
Answer: DVD Video
The answer here is simple: Someone possessing clue needs to reverse engineer the protocol, and open soruce an application which can "simulate" any of the "permitted" applications. (e.g., so that OpenCCVS can pretend to be CCVS, or any other credit card verification software).
You know that each individual verification application must have some "fingerprint" or signature, because an individual application has to be "permitted" to connect, so there must be some licensing or keying going on to permit that. This is analagous to the many keys that the DeCSS people discovered.
When you create the Open Source version, it is one which the clearing houses cannot prevent, because it can present the appropriate protocols as though it was coming from any of the licensed applications. What are they going to do? Kill all the existing licensees and make them retool to a new system? Forget it, they had enough problem getting credit-card swipes reconfigured to handle Y2K expirations, they ain't gonna redo the whole authentication scheme.
All this needs is someone to commit the time to doing it.
D
Security through obscurity is the only thing that people understand. Maybe they're wrong, but maybe they're right. It falls once again into an issue of information. WE ARE HIPPOCRITS. We want all information to be free, but mandate privacy. See a discrepancy there?
You completely miss the point. Personal privacy is *NOT* the same thing as proprietary corporate information. I'm not asking which hand you wank with, i'm asking for proof that you are being responsible with the private personal information that you are asking me to trust you with. If my personal privacy depends on the security of your proprietary protocols, I want a better garantee than "trust me" that i am being protected.
If anyone is a hypocrite it is YOU for expecting me to give corporations my private info and not expect them to prove to me that they're protecting it.
This isn't flamebait, but it should get an "Inciteful." You say that there is a difference, no, there isn't. If those companies that are being requested by you to give all of their information to you asked you for yours, what would you say?
What *would* i say? Have you ever had a bank account? A credit card? A car? A drivers license? They ask for pleanty of private information. I suppose you're happy just keeping your fingers crossed that they know how to keep it secure?
That aside, i'm not asking them for their financial records, etc. Nothing as private as what *they're* asking *me* for.
How many are still using cobol?
/. gets excited about the re-implementation of a 30 year old operating system?
Huh? Banks are slow and monolithic because they use a 40 year old programming language, but everyone on
DrLunch.com The site that tells you what's for lunch!
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be
You almost say that like its a bad thing or something.
DrLunch.com The site that tells you what's for lunch!
Right, if the banks refuse to release source we have to reverse engineer the program or use it as closed source. No way around it, and RedHat can't make the banks do otherwise.
But... as a previous poster said, talking to your bank about wanting the software and protocols made available might work, if you point out that open source software can be trusted in a way closed source can't. They'll be reluctant, but if they realize it's a good thing, both for the customers, and for them, because they can use it to show they're not making any horrid mistakes in their code, they might be interested.
So, ask your bank. Fax the manager a letter and explain that for your security review you need to know the security procedures of the companies you're working with, like with y2k preparadness, you can't be in business if your supliers are down.
This is a common misconception. Encryption algorithms can be proven (mathematically) to be impratical to break without break-thoughs in decryption algorithms.
Security flaws usually come in the implementation of those algorithms, and in the supporting code around them.
They're probably also worried that open-sourcing their protocols might lead to cyber attacks on their clearinghouses.
They're wrong, of course - mainly because Security through Obscurity doesn't work. But try to tell that to a suit.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I disagree...worldwide, banks and financial institutions in general were the first sectors of society to report Y2K compliance. Furthermore, they make more money when their systems work faster and process more transactions. I think it was Citibank who said that the new system they implemented recently allows them to clear checks up to four hours sooner everynight. For banks, money is like product; its worthless until its moved. Therefore, they'll climb over each other to implement tools that help them do this. Of course, they're going to take their time and make sure its safe and secure...if you're refering to that process being slow, well, I just got my dentist's degree from Sally Struthers. Got a toothache? I didn't think so...
"Nobody owns the fucking words man." - James Dean
I was just reading the yahoo article and I took a look at the Red Hat Store where you can buy the Professional Edition, which includes some e-commerce stuff (among other things) that isn't in the standard freely available edition... or is it? I guess this means no free e-commerce APIs?
Just wondering...
BTW, what would be more difficult: doing an open-source e-commerce API (which would undoubtedly increase e-comm revenues by sheer volume) or to convince the banks, etc., to support this development (replace NDAs with sane, well-designed protocols, etc.)? The trick would be convincing the big players that letting "anyone" do e-commerce would increase revenues more than charging for the privilege---it's all about transaction volume (you have to think of the spin-off benefits).
For example, I don't need to pay a bank to use cash (thier current "open" protocol) but they make money from the side-effects of that cash transaction (banking, investment, loans, everything really).
--8<--
Sad to admit it, this is what the bank will read from this letter.
"Hi, I am currently a customer of your bank. I am interested in online banking and making special withdrawals (especially with links to e-commerce), but as an anarchist I know that the only good security is open security. Please send me the source code/protocols/etc of your online security system so I can evaluate it against my capabilities. I will only be considering financial institutions that can make me feel comfortable with their security."
I do what the voices on my console tell me to do.
Basically, that is my understanding as well. However, blame doesn't really come into it as much as one might think. There is not an easy way for these banks, etc. to change things from the current system without dropping a few billion dollars in the U. S. alone. Unless someone wants to remodularize their entire software systems that track billions of transactions on a really good day. The change to open source, or any other change, is a financial mountain to hurdle.
In short, keep in mind that the cost for them to repay the full value of all the stolen money and wrongful charges in a year is likely to be miniscule in comparison to the cost of replacing CCVS. As much as we might grumble about it, the banks will do what saves them money in the short run until the need to change it becomes sufficiently great. This is the way business works. A less than ideal product that is in place is better than paying two years income to replace it.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
Hey, they are not slow to change! Why, just last year my bank traded in their mechanical calculators for ones made with transistors!
Mike Eckardt meckardt@spam.yahoo.com
Knew that the red capped software company was heading into an alliance to enhance their business strategy, but frankly Hell's Kitchen comes as a surprise. I was really wishing their merger was to a certain red-roofed leader in convenience dining...
websiteparodies.com/redhut
---
"And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold."
-----
Cast a Cold Eye
On Life, on Death
Horseman, pass by
--W.B. Yeats' gravestone
I don't think banks can be expected to embrace open source anytime soon. They are slow monolithic beasts. How many are still using cobol?
There are about a zillion laws against this kind of thing, and unless they've got really deep pockets they could find themselves in VERY serious trouble (like, the kind of trouble that completely ruins your finances, forever).
If someone detects this "extracurricular" activity on their credit cards, they can complain to the card issuer. If the issuer gets enough complaints, they'll come after your friends with lawyers -- the individual customers won't have to spend a dime in legal fees. The gigantic financial institution will take care of that for them . . .
I have no
http://www.redhat.com/about/2000/pr ess_HKS.html
The install is really rough, but the system works well. I have used it a few times for web sites and would choose it again. I don't work for Hell's Kitchen, I just like CCVS.
The closed source issue goes beyond NDAs. The clearing houses require that the software be certified to work with their systems in order for it to connect. They loose control of that certification if they allow anyone to release open source credit card software. Don't blame Red Hat or Hell's Kitchen, blame the clearing houses and merchant banks.
If "we" did want all information to be free and still demanded our privacy, we would indeed be hypocrites. But we don't. Some people say "information wants to be free" but not all of us say that and those who do don't always mean what you appear to think they do.
When we demand openness, we aren't asking to see the data stored within systems, but the code that runs the system -- the very code we want to ensure is good enough to protect our privacy among other things.
--
Fuck the system? Nah, you might catch something.
Wouldn't an open source credit card verification system be a Bad Thing(tm)? I would assume that this would make it easier to engineer the ablility to compromise the transaction. I know that security through obscurity is a bad policy by nature, but in these types of things, is it not required?
Not really, no. Well-designed secure protocols retain their security even when all of the participants know all the details of the protocol, and even when one or more of the participants is malicious.
If it makes a difference whether or not people know the full protocol, then it's a sign that the protocol isn't really secure in the first place. It's a sign that you already have a problem.
If you're relying on secrecy of the protocol to protect the integrity of the protocol, then you are SOL the moment someone finds out the details. That wouldn't necessarily mean you told them, either; they could have reverse-engineered without your knowledge, or been told by someone who knew (there wouldn't necessarily be any specific way of tracing the leak, either).
Obviously, secrets are in fact required for security, but that secrecy should be concentratd in well-defined and controllable things like encryption keys that individual people are responsible for.
Think about any multiuser OS in a secure configuration (I'll use a secured Unix as an example here) -- is the system secure because the users don't know how it works, or because it really is secure?
Relying on the obscurity of your protocol for security is like giving the root password to all of your users, and then trying to keep them from learning any more about Unix so they won't know enough to do anything malicious.
What you want to do instead is give them individual accounts, with individual passwords (secrets) and individual accountability, with access controls in place to prevent them from doing anything malicious. It's hard work, but protocols can be designed this way.
"Security Through Obscurity" doesn't really help; it just hides the problem from everyone but the people who have found a way to exploit it until it's too late.
Look at the situation with cheating and the Open Sourced Quake -- there have been the same kind of cheats (aimbots, b0rked models, modified rendering and so forth) long before Quake was open-sourced. The only substantial effect Open-Sourcing had in the case of Quake was making the people who weren't already cheating aware of the specific problems, and the exploits marginally more accessible.
Don't just take this from me, I would strongly encourage you to read books like "Applied Cryptography" by Bruce Schnier to get a better understanding of these issues.
DNA just wants to be free...
You may be surprised at the number of banks that are potentially clueful.
Where you are going to run into serious problems is with the regulatory institutions, such as the FDIC, FFIEC, NCUA, etc.
Theseguys are the tough nuts to crack. I can tell you from first hand experience that they take privacy and security very seriously.
Supposed data processing specialists in the examiners offices are utterly mystified in many respects. They wouldn't know an AS/400 from a 300 bowling game. They have an armlock on the software companies, forcing them to hold source code in escrow with a third party, so that no one other than the company messes with it, and so that (surprise) they can peruse it at will.
The whole open source concept would be entirely foreign and entirely unacceptable to them, however , that is where headway needs to be made.
What you'll hear from the banks, to a one, is this, "Will it pass muster with the examiners?"
In this case, the answer would be a resounding NO.
"It's not perfect, but until the banks get clueful, it's the best we can hope for."
Right, so let's all sit around and hope they get clueful.
How about this instead: Send them a clue. By email, by boycotts, by not buying HKS, etc.
For instance, why not send your bank something based on the following: "Hi, I am currently a customer of your bank. I am interested in online banking (especially with links to e-commerce), but as an IT professional I know that the only good security is open security. Please send me the source code/protocols/etc of your online security system so I can evaluate it against my needs. I will only be considering financial institutions that can make me feel comfortable with their security."
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
HKS's acquisition by Red Hat is probably a good thing. It gives them a bigger company behind them, allowing them to push more money into development. Hopefully they'll be competing with some of the big processing software like ICVerify.
However, it's really important that they get some more functionality in the base of the software first. Major technical limitations make CCVS a poor choice in hardcore processing environments.
I was setting this up for a client who was processing CC's pretty seriously - thousands of authentications per day. The biggest problem we ran into with CCVS was that it kept separate files for each transaction being processed. Each file would contain the transaction ID that you assign. To find any information out about a transaction, it opened every transaction file to find out the information you requested.
Meaning, simply, that the machine was coming to it's knees after a few days simply because of a poor way to store transactions. This could have been cut down to a few hits to the filesystem, had a schema as simple as naming the file after the transaction ID been implemented.
Plus we had assorted modem problems. HKS was always very helpful with us. Unfortunately, I had to replace the Linux box running CCVS with a SCO box running ICVerify before my client could really go into production mode. Yuck.
In any case, it would be very difficult to write an open source credit card processing program. Technically, all the protocols (at least most of the major ones) are pretty simple, and could be implemented quickly. The problem is that with the clearinghouses.
The clearinghouses are glad to hear that you want to develop processing software. To them, third-party processing software means money. If you want to talk to them, you pay them. Before your software is allowed to communicate with a credit card processor, it has to pass their tests to ensure that it does the right things. To get your software tested, you have to pay. Plus you typically have to license the protocols, you pay again.
Of course, it would be possible to start a company with some funding to create an open source credit card processor. But you're signing NDA's before you can see the protocol specs. They don't want that out there in the public, and they won't let you open source the code to speak their protocols.
It would still be possible to write an open source processor, by watching the serial I/O of an established processor and reverse engineering it. But then you're putting out software that the clearinghouse doesn't approve of. Which means that they can refuse to deal with a merchant until they get the appropriate software.
Which means a merchant might be denied money. Given the choice, most people will shell out the $x for a commercial, proprietary processor rather than risk losing their merchant account.
Of course, when I say "the clearinghouses", I'm only referring to the ones I've talked to. Hopefully, if they got enough mail about it, they might consider allowing open source software to talk to them. So if you want to see an open source CC processor, or care about the open source movement, you should mail the clearinghouses about this. I'd start with First Data Corp.
Hrm, I see your point - sort of. If your 190GHz Athlon can't run GnomeIII, then why aren't you running WindowReMaker? You've got the source, and it only requires 10GHz.
Skip Mozilla 18.63, too - Armadillo surpassed it in speed and stability long ago.
As for your boss, just happily tell him you're running Red Hat (keep the splash screen) and run your BSD. With the Linux acceleration layer, nobody will know.
My point - open source is open source, and I could care less who buys what company, for the most part.
----
I could go into long and boring detail about what each of the messages do, but to preserve sanity, I will refrain.
What is "closed" is who the banks will talk to with this protocol. This is a "good thing" (tm). You are required to have your product certified by the bank by a test regime that they require to be performed.
So, you can get a copy of AS2805, write a gateway (open or closed source, your choice) and talk to your local bank about getting an expensive X.25 connection to them, and you can pass financial transactions (in my case credit card transactions) to the banking network.
How do I know ? Well, I've done it.
The company previously known as ABA (now eSec) built a real-time credit-card transaction system all in Java. I was one of 6 programmers involved in the development.
Offtopic rant: There is some desperate need for many of the Slashdotters to do some research or thinking _before_ posting. The editors posting stories should also be a lot more responsible in their editorial comments. Slashdot has recently become a very "bandwagoneer" production which is starting to mimic the popular press.
Lift your game, or lose your readers.
Please, emmett, do tell. Why did you include that bit of editorial comment in a redhat story?
Was that a news story or opinion? Do I get a chance to read the story and decide for myself what opinion to form?
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be.
Why can't Red Hat let anyone else into the market? Ever since they drove Microsoft into bankruptcy they've bought every conceivable service on the planet. They have their little red logo on everything, and whenever someone looks to buy an OS it's either Apple or Red Hat. Why do they have to bundle every conceivable service with their systems??? I want to go with a BSD at work, but my boss won't let us because "Everything works better if it's all Red Hat." 90% market share is a pain in the neck no mater who has it. And while I'm on it, why do I need an Athelon 190 Gigahertz and half Tetrabyte of Ram to run their GUI?!?!?!?! I remember when a Merced with a gig of ram was all you needed for SERIOUS computing!
BTW: Mozilla 18.63 still sucks. No browser download should be 200 megs. What happened to the nice, clean, small 40 meg download from not too long ago. It's getting to the point where us poor cheapskates with a pokey SDSL connection can't get along anymore!
"Live Free or Die." Don't like it? Then keep out of the USA