> -----Original Message----- > From: Shachar Shemesh [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 7:51 AM > To: Guy Teverovsky > Cc: Linux-IL mailing list > Subject: Re: Fw: What's wrong with this code? > > > Guy Teverovsky wrote: > > >On Thu, 2003-11-13 at 10:46, Gilad Ben-Yossef wrote: > > > > > >>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). > > > 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. > > 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. > > > 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. > > > 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. > > 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 Rational > >(or should I say IBM ?) is a good example of such an application. > > > > > Lets 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.
While agreeing with most of your post, I can testify to previously working for a company with a state-of-the-art ClearCase implementation. Each R&D team has it's own branch to work on, and only the integration team merged files from these branches to our /main branch. Furthermore, each feature had its own branch, which was merged to relevant team branches once matured and tested. Yes, this definitely isn't ClearCase 101, but I agree with Shachar that the companies (in Israel, anyway) using a good version control system and matching procedures can be counted on one hand of former army Engineer. > 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 worst > >fears is the industrial espionage and sabotage by your competitors. > > > > > While 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). > > 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. Again, here you're wrong. The company I work for currently does not allow engineers access to code they have no business reading in the first place. Of course, a malicious programmer can always social engineer his way into getting access to the code. > >>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. > > > > > 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. > > 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. > > >>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. > > > 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. > > Let's face it - the market simply doesn't work this way. > > > OS or closed source world, it doesn't matter. > >It can happen anywhere and it all depends on the proficiency and > >skillfulness of the ones on the watch. > > > > > 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. > > >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] > Shachar Tal Verint Systems This electronic message contains information from Verint Systems, which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by replying to this email. ================================================================= 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]
