On Thu, 2003-11-13 at 10:46, Gilad Ben-Yossef wrote:Hmm - you must have better info about closed source companies than I do. Those I know either don't use source control at all, use Visual Source Safe (a.k.a. check repository once a week or there WILL be data corruption), or use CVS.
Now, what would have happend if this was a run of the mill closed source security firm?
Closed source firms rarely use CVS (if ever).
I know one rather big company that started forcing a migration from CVS to rational down their developer's throat. When the migration was 80% done, the sheer pressure from the developers stopped the process.
As has been established in the previous paragraph, you are talking about commercial companies that live in a different world than the ones I know.Big projects usually rely on version control mechanisms with integrated version tracking, logging and authentication mechanisms (user, time, machine, file, branch, etc... where the file was checked-in). Pure mortal developers do not have the permissions to perform merges with main branches.
Even if permission based restriction were applied - if a company has a procedure that requires one set of eyes to review a change before it goes in, you would call that a "highly quality aware company" (and wouldn't be enforced by passwords anyhow). Even so, big changes rarely go in after line-by-line peer review. When the merges occure, the project manager has little ability to know the specifics of each and every line of code several dozens developers wrote. The merge process is usually a mere verification that the change makes sense in it's new environment. The slightest discrepancies are forwarded to the person who wrote the original code to clear out.
ClearCase by RationalLets separate what the app can do, with the way it is being typically deployed. I am yet to see a deployment of clearcase where developers were given commit access to certain parts of a program, but not to others. You can define code owners for code areas, and enforce that each commit to a given code be approved (or at least acknoledged) by the relevant owner. This can be done in CVS too, however.
(or should I say IBM ?) is a good example of such an application.
In any case, assuming the developer is qualified to write production code, they can write code that gets CPU time on a client's machine. As such, they can backdoor the product.
In short - there is plenty room for a single developer to backdoor a commercial product. This goes for any commercial environment.
You might forget it, but in the proprietary code world one of your worstWhile I have heard rumors of soure code leaking left and right, actual code sabotage is pretty rare. After all, a competitor is more interested in what I've done, than in introducing a back door into my product that noone is likely to find about anyways. As such, sabotage is pretty low on most IT managers and CEOs list of threats. Most don't even see IP leaking as a major threat (not by internal developers).
fears is the industrial espionage and sabotage by your competitors.
As such, it is worth noting that I am yet to see a commercial company where, as a rule, one developer does not have source code access to the entire company's product suite. There are exceptions (a release the company is trying to keep a secret, government contracts, clean room reverse engineering), but they are just that - exceptions.
I'm afraid you are too optimistic about "should" vs. "does". A sysadmin has but one thing on his mind - keep the beeper from ringing in the middle of a weekend. Good sysadmins aim for that goal by making the system reliable. Bad admins aim by imposing strict rules and making sure that noone tries to do too much. Either way, very few admins will take extra measures beyond their call of duty.First of all, I seriously doubt it that the fact of the change would have been detected at all, but even if it were the sys admin discovering it would "fix the technical problem" and would never ever send it to the R&D (which are another dept. which is hated by the IT team).SysAdmin who does not see the benefits in cooperating with R&D team
should be whipped with GigaEthernet cables.
R&D are customers for a sysadmin. The more they are, and the more involved they are, the less reliable the system (good sysadmin) and the more their incompetance is shown (bad sysadmin), and the beeper is more likely to go off on a weekend.
Wellll. MS has had bad vulnerabilities for years uncounted. It is only now begining to affect their bottom line. While not the company with the worst code in the world, it is definitely the company with the worst image as far as laymen are concerned. Anyone else has even less of an incentive to fix security bugs.In short - people breaking in and putting in back door happen in both open and closed source. But only in Open SOurce there's a real chance that someone would discover it. In closed source land it's always "someone else's problem".
Compromised code is a ticking bomb that can blow up any second and scare away your customers.
Let's face it - the market simply doesn't work this way.
OS or closed source world, it doesn't matter.No. I think it depends more on the awareness and priority given by the entity in question. I know commercial companies that care very much, whether it directly affects them or not, and I know companies that couldn't give a damn. With open source - it's more difficult not to give a damn.
It can happen anywhere and it all depends on the proficiency and
skillfulness of the ones on the watch.
Guy
Shachar --
Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
