Re: Fw: What's wrong with this code?
On Mon, 17 Nov 2003, Gilad Ben-Yossef wrote: > On Monday 17 November 2003 08:41, Tal, Shachar wrote: > > > It makes it harder, as diffs are examined (by a single person or two > > people) before introducing code to the main branch. > > It's possible to obfuscate a backdoor, of course, but harder than > > when no one is watching. > > Or to put it shorty: > > > Bad closed source company: no one watches the code. > Good closed source comapny: one or two person watches the code. > Open Source: ~10k of the world best programmer watch the code. I get the impression that in practice the number of people who actually watch any given piece of open source code is significantly smaller, and, ufortunately, the number of people who use any given piece of code without ever taking a look is big - some of them reason that it must be good because of said ~10k. > > Take your pick.. :-) Best tool for the job. Some of them are open source, some are not. > Gilad > > = > 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] > -- Thanks, Uri http://translation.israel.net = 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]
RE: Fw: What's wrong with this code?
> -Original Message- > From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 2:01 PM > To: '[EMAIL PROTECTED]' > Subject: Re: Fw: What's wrong with this code? > > > "Tal, Shachar" <[EMAIL PROTECTED]> writes: > > > If I need access to code which I am not "privileged" for, I ask for > > it, and bang, 15 seconds later I have access to it. No big > > "fill-forms-in-three-copies-then-chase-disgruntled-IT-people" deal. > > This seems to me a contradiction to what you wrote earlier. To quote: > > "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." How is that contradiction? Does not allow != VP R&D signs approval forms. When I need access to code X, I ask the person in charge of that for access, and he either gives it to me or not, based on the reasons I give him. If he doesn't, I either flog him with really long SATA cable or talk to his boss. > > > The point I try to drive is, you don't need good reasons to > > compartmentalize. You need good reasons not to. > > I said nothing about "compartmentalization," whatever meaning you care > to put into the word. I remarked on the passage quoted above, saying > that reasons to do that were few and far between. > > > Well, most tools do exist (e.g. source control, automated testing, > > UML code generator) for 99.9% per cent of the companies, who deal > > mostly with standard software engineering. The other 0.1% may > > require exotic tools (e.g. I have no idea how to test VMWare > > without special tools). > > I am guessing wildly. It seems that your notion of "standard software > engineering" differs from mine. I suspect you assign all the different > things I did and all the things I am doing to 0.1% of "exotic" > activities. Dealing with VMWare does not seem exotic at all to me... You misunderstood my example. I did not mean *using* VMWare, I meant *testing* VMWare (as the VMWare vendor). > > > If you know how to reach a ratio of internal to customer > code of more > > > than 10:1 (apart from Excel macros), and produce decent > customer code, > > > would you consider sharing the insights? > > > > You seem to either be really amazed by what I said. People, > am I the only > > one in the forum who thinks that most code written is production > > code? > > Don't confuse between production code and customer code. Internal code > (including all the examples you gave, which are good but few) can be > production. > > There is ample anecdotal evidence of surveys done at software > development conferences of how many programmers work on customer > deliverables. The numbers usually quoted are in the range of 95% code > written for internal consumption. Last time I personally was present > when this kind of question was asked was at Go-Linux in spring. A > speaker asked a big hall full of people who developed software for a > living (a good portion of the audience raised hands) and then who > wrote code sold to customers (2 or 3 hands). I find it extremely hard to believe. I' think that the business model of the employers of those present at that Go-Linux is skewed in a sick, sick way (assuming open-source is still a long way from being profitable for any but a select few). Every single person in the my development group is developing code that is sold to customers. Previous jobs had roughly the same percentile of "money-bringing" people (surely all had >90% money earners). > In every company I worked for internal scaffolding was > done. Prototypes, demos, tons of debugging code and tools specific to > the domain, research tools, simulators for hardware and software, > independent implementations of different solutions only one of which > ultimately became production, customization and fixing of existing > software and libraries, throw-away code to try things out, you name > it. > > A situation where you have tools that generate ready production code > for you, verify it, generate automatic builds, testing, and all the > rest of the scaffolding, sounds really exotic to me. To tersely comment on these long paragraphs: I never worked for companies who waste their resources writing prototypes and demos that never ended as production code. It's not that I select my jobs that way, it just never happened. I suspect such companies either have deep pockets to fund these activities, or they go under ve
Re: Fw: What's wrong with this code?
"Tal, Shachar" <[EMAIL PROTECTED]> writes: > If I need access to code which I am not "privileged" for, I ask for > it, and bang, 15 seconds later I have access to it. No big > "fill-forms-in-three-copies-then-chase-disgruntled-IT-people" deal. This seems to me a contradiction to what you wrote earlier. To quote: "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." > The point I try to drive is, you don't need good reasons to > compartmentalize. You need good reasons not to. I said nothing about "compartmentalization," whatever meaning you care to put into the word. I remarked on the passage quoted above, saying that reasons to do that were few and far between. > Well, most tools do exist (e.g. source control, automated testing, > UML code generator) for 99.9% per cent of the companies, who deal > mostly with standard software engineering. The other 0.1% may > require exotic tools (e.g. I have no idea how to test VMWare > without special tools). I am guessing wildly. It seems that your notion of "standard software engineering" differs from mine. I suspect you assign all the different things I did and all the things I am doing to 0.1% of "exotic" activities. Dealing with VMWare does not seem exotic at all to me... > > If you know how to reach a ratio of internal to customer code of more > > than 10:1 (apart from Excel macros), and produce decent customer code, > > would you consider sharing the insights? > > You seem to either be really amazed by what I said. People, am I the only > one in the forum who thinks that most code written is production > code? Don't confuse between production code and customer code. Internal code (including all the examples you gave, which are good but few) can be production. There is ample anecdotal evidence of surveys done at software development conferences of how many programmers work on customer deliverables. The numbers usually quoted are in the range of 95% code written for internal consumption. Last time I personally was present when this kind of question was asked was at Go-Linux in spring. A speaker asked a big hall full of people who developed software for a living (a good portion of the audience raised hands) and then who wrote code sold to customers (2 or 3 hands). In every company I worked for internal scaffolding was done. Prototypes, demos, tons of debugging code and tools specific to the domain, research tools, simulators for hardware and software, independent implementations of different solutions only one of which ultimately became production, customization and fixing of existing software and libraries, throw-away code to try things out, you name it. A situation where you have tools that generate ready production code for you, verify it, generate automatic builds, testing, and all the rest of the scaffolding, sounds really exotic to me. OK, this random-walked really far away from linux-il. -- Oleg Goldshmidt | [EMAIL PROTECTED] = 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]
RE: Fw: What's wrong with this code?
Hi Oleg, > -Original Message- > From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 10:28 AM > To: Tal, Shachar > Cc: '[EMAIL PROTECTED]'; 'Shachar Shemesh'; Guy Teverovsky > Subject: Re: Fw: What's wrong with this code? > > > "Tal, Shachar" <[EMAIL PROTECTED]> writes: > > > I have no idea what you're talking about. > > More is the pity. Let me try to explain myself in a couple of simple > sentences. To be a good software engineer, you need to read other > people's code. To develop programs efficiently, you need to show your > code to other people. A company that does not encourage these two > activities whenever possible does not utilize the full potential of > its developers (and I am being generous). IMHO, you need a very good > reason *not* to do it. Reason below. > > Being an IBM employee, I'm sure you are aware of software systems > > that are larger than any single person's perceptional abilities. > > Working on a multi-hundred man-years software, I seldom need to > > access code for subsystems I don't develop or maintain, and even > > more seldom need to understand its inner workings. Design documents > > are usually satisfactory. > > I never said you must read and learn *all* the code developed at your > company. I only said that unless there are compelling reasons > preventing this you should be able to access as much code as > possible. What I said was generic, not IBM-specific. Rest assured, my code is being read by others and I read other people's code. But not *everybody* read my code, nor do I bother with readying everybody's code. We use a buddy system. We have teams, each is in charge of specific subsystems. Inside teams, people read other peoples' code *all* the time by definition, since we do code reviews. Outside of teams, we have knowledge transfer sessions, both at top-level design stuff and low-level code stuff. And, yes, we consult with people from other teams when the need arises and sometimes when it doesn't. But I don't really need access to all code on a regular basis. Nor can I understand most of it (under the famous 30-second test) without guidance anyway. And it would be a wise precaution to compartmentalize, just in case I have very weak passwords *and* I leave my modem and PCAnywhere (with null password) up for the weekend, in case I may want to connect to work. You seem to view compartmentalizing as a tedious process, Dilbert-style. I do not. If I need access to code which I am not "privileged" for, I ask for it, and bang, 15 seconds later I have access to it. No big "fill-forms-in-three-copies-then-chase-disgruntled-IT-people" deal. The point I try to drive is, you don't need good reasons to compartmentalize. You need good reasons not to. > > As for internal consumption vs. customer consumption - perhaps IBM > > can afford writing a lot of software for internal consumption. Most > > companies first write customer software then internal software. > > These companies must be living in a dream world where everything they > need for development actually exists before they start. I have worked > for tiny struggling startups and for multibillion dollar > multinationals > - it's not a matter of money. This was not the case in any of them, > and I have never heard of any case like that. You first create the > scaffolding, then you build. You create more scaffolding as you build. Well, most tools do exist (e.g. source control, automated testing, UML code generator) for 99.9% per cent of the companies, who deal mostly with standard software engineering. The other 0.1% may require exotic tools (e.g. I have no idea how to test VMWare without special tools). > > Granted, software is written internally everywhere (test suites, > > load suites, code generators, various automation efforts, even the > > sales people need Excel macros to compute what to charge a > > customer). But not as much as written for customer consumption. > > If you know how to reach a ratio of internal to customer code of more > than 10:1 (apart from Excel macros), and produce decent customer code, > would you consider sharing the insights? You seem to either be really amazed by what I said. People, am I the only one in the forum who thinks that most code written is production code? Shachar. 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 y
Re: Fw: What's wrong with this code?
"Tal, Shachar" <[EMAIL PROTECTED]> writes: > I have no idea what you're talking about. More is the pity. Let me try to explain myself in a couple of simple sentences. To be a good software engineer, you need to read other people's code. To develop programs efficiently, you need to show your code to other people. A company that does not encourage these two activities whenever possible does not utilize the full potential of its developers (and I am being generous). IMHO, you need a very good reason *not* to do it. > Being an IBM employee, I'm sure you are aware of software systems > that are larger than any single person's perceptional abilities. > Working on a multi-hundred man-years software, I seldom need to > access code for subsystems I don't develop or maintain, and even > more seldom need to understand its inner workings. Design documents > are usually satisfactory. I never said you must read and learn *all* the code developed at your company. I only said that unless there are compelling reasons preventing this you should be able to access as much code as possible. What I said was generic, not IBM-specific. > As for internal consumption vs. customer consumption - perhaps IBM > can afford writing a lot of software for internal consumption. Most > companies first write customer software then internal software. These companies must be living in a dream world where everything they need for development actually exists before they start. I have worked for tiny struggling startups and for multibillion dollar multinationals - it's not a matter of money. This was not the case in any of them, and I have never heard of any case like that. You first create the scaffolding, then you build. You create more scaffolding as you build. > Granted, software is written internally everywhere (test suites, > load suites, code generators, various automation efforts, even the > sales people need Excel macros to compute what to charge a > customer). But not as much as written for customer consumption. If you know how to reach a ratio of internal to customer code of more than 10:1 (apart from Excel macros), and produce decent customer code, would you consider sharing the insights? -- Oleg Goldshmidt | [EMAIL PROTECTED] = 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]
RE: Fw: What's wrong with this code?
> -Original Message- > From: Oleg Goldshmidt [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 8:40 PM > To: Tal, Shachar > Cc: 'Shachar Shemesh'; Guy Teverovsky; Linux-IL mailing list > Subject: Re: Fw: What's wrong with this code? > > > > The company I work for currently does not allow engineers access to > > code they have no business reading in the first place. > > They must have a *really* good reason for it. The disadvantages of > this approach are too many to count. The more code your programmers > read the better code they will write. External security restrictions > or "clean room" requirements can justify this, but hardly anything > else. In any case, the above exceptions should be just that - > exceptions. Usually companies write more code for internal consumption > than for customers. I have no idea what you're talking about. Being an IBM employee, I'm sure you are aware of software systems that are larger than any single person's perceptional abilities. Working on a multi-hundred man-years software, I seldom need to access code for subsystems I don't develop or maintain, and even more seldom need to understand its inner workings. Design documents are usually satisfactory. As for internal consumption vs. customer consumption - perhaps IBM can afford writing a lot of software for internal consumption. Most companies first write customer software then internal software. Granted, software is written internally everywhere (test suites, load suites, code generators, various automation efforts, even the sales people need Excel macros to compute what to charge a customer). But not as much as written for customer consumption. Shachar. 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]
Re: Fw: What's wrong with this code?
"Tal, Shachar" <[EMAIL PROTECTED]> writes: > > From: Shachar Shemesh [mailto:[EMAIL PROTECTED] > > > > 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. UNIX permissions would suffice, actually, on a per-module basis. > 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. I may be missing something, but at first glace there is nothing here that cannot be done with CVS. Ouch! What have I done?! I am an IBM employee, and now I am saying that an amateurish piece of half-baked open source code can do what a "state of the art" instance of proprietary "software configuration" tool can do? Wait... I use CVS at work... ;-) > The company I work for currently does not allow engineers access to > code they have no business reading in the first place. They must have a *really* good reason for it. The disadvantages of this approach are too many to count. The more code your programmers read the better code they will write. External security restrictions or "clean room" requirements can justify this, but hardly anything else. In any case, the above exceptions should be just that - exceptions. Usually companies write more code for internal consumption than for customers. -- Oleg Goldshmidt | [EMAIL PROTECTED] = 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]
RE: Fw: What's wrong with this code?
-Original Message- From: Muli Ben-Yehuda [mailto:[EMAIL PROTECTED] [snip] > > Abandoned open source: No one watches the code. Ever. No one knows > > where to find it. Only binaries are left, and only on ftp.funet.fi > > and only in some obscure folder. > If no sources are left, it's not open source, is it? Sometimes the sources are no longer available because the original homepage domain is no longer registered, it's not GNU, and some binary package is in simtel or similar repository. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** 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]
Re: Fw: What's wrong with this code?
On Mon, Nov 17, 2003 at 05:21:21PM +0200, Arik Baratz wrote: > Abandoned open source: No one watches the code. Ever. No one knows > where to find it. Only binaries are left, and only on ftp.funet.fi > and only in some obscure folder. If no sources are left, it's not open source, is it? Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ "the nucleus of linux oscillates my world" - [EMAIL PROTECTED] signature.asc Description: Digital signature
RE: Fw: What's wrong with this code?
-Original Message- From: Gilad Ben-Yossef [mailto:[EMAIL PROTECTED] [snip] > Bad closed source company: no one watches the code. > Good closed source comapny: one or two person watches the code. > Open Source: ~10k of the world best programmer watch the code. I think you should rather say: Popular open source: ~10k of the world's best programmers watch the code. Unpopular open source: One of the maintainers watch the code, occasionally, when he introduces new code. Abandoned open source: No one watches the code. Ever. No one knows where to find it. Only binaries are left, and only on ftp.funet.fi and only in some obscure folder. -- Arik ** This email and attachments have been scanned for potential proprietary or sensitive information leakage. PortAuthority(TM) Server Keeping Information Inside Vidius, Inc. www.vidius.com ** 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]
Re: Fw: What's wrong with this code?
On Monday 17 November 2003 08:41, Tal, Shachar wrote: > It makes it harder, as diffs are examined (by a single person or two > people) before introducing code to the main branch. > It's possible to obfuscate a backdoor, of course, but harder than > when no one is watching. Or to put it shorty: Bad closed source company: no one watches the code. Good closed source comapny: one or two person watches the code. Open Source: ~10k of the world best programmer watch the code. Take your pick.. :-) Gilad = 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]
RE: Fw: What's wrong with this code?
> -Original Message- > From: Shachar Shemesh [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 8:38 AM > To: Tal, Shachar > Cc: Guy Teverovsky; Linux-IL mailing list > Subject: Re: Fw: What's wrong with this code? > > > Tal, Shachar wrote: > > >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. > > > Would you say that this prevents a single developer, on a whim, from > introducing a backdoor? It makes it harder, as diffs are examined (by a single person or two people) before introducing code to the main branch. It's possible to obfuscate a backdoor, of course, but harder than when no one is watching. > > 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. > > > > > > > I was also making the point that, even if all procedures were > in place, > a backdoor can still be introduced. See my next sentance from my > original mail. I'll grant you that. > >>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. > >> > >> > ... > > >>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. > > > > > > > Hmm. Doesn't your company fall under the second case in my > "exceptions" > list? A part of the company does. I'm not talking about that specific part, since I don't work for that part. 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]
Re: Fw: What's wrong with this code?
Tal, Shachar wrote: 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. Would you say that this prevents a single developer, on a whim, from introducing a backdoor? 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. I was also making the point that, even if all procedures were in place, a backdoor can still be introduced. See my next sentance from my original mail. 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. .. 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. Hmm. Doesn't your company fall under the second case in my "exceptions" list? 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]
RE: Fw: What's wrong with this code?
> -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 en
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. 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. 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. We. MS has had bad vulnerabilities for years uncounted. It is only now begining to affect their bottom line. While
Re: Fw: What's wrong with this code?
Reminder: to master the art of distinguishing between "Reply" and "Reply to all" Guy 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). 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. ClearCase by Rational (or should I say IBM ?) is a good example of such an application. You might forget it, but in the proprietary code world one of your worst fears is the industrial espionage and sabotage by your competitors. > 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. > 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. 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. Guy -- = 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]
Re: Fw: What's wrong with this code?
On Thursday 13 November 2003 12:11, Boaz Rymland wrote: > In short - there is a weak point in the openness model. it is greatly > acknowledged and treated hence achieving a better security model. Don't > be impressed by the publicity it gets - you just dont hear of such cases > in closed source organizations. I wouldn't call it a weaknes in the openess model, maybe a weakness in the PR case of open source. The problem exists in both closed and open software, it's just that open source software cannot hide it. Therefore: a. It's visible. b. Open Source software put in place to handle the issue, as much as it can be handled. The interesting question (for me, at least) is: "are we doing a good job of handling the problem?" My feeling about the answer is that we are doing a terrible job, but it's still better then closed source software which are simply denying the problem exists and doing nothing, because they can get away with it. Gilad -- Gilad Ben-Yossef <[EMAIL PROTECTED]> Codefidence. A name you can trust (tm) http://www.codefidence.com "Half of one of my eyes is already open. I'm going to make coffee now..." -- Kathi 16:08:04 = 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]
Re: Fw: What's wrong with this code?
Well, you certainly got a point there. One could claim that such source compromises are possible with closed source SW too and in such a case, indeed logical to assume, it is more difficulty finding, verifying and correcting the code AND, closing the security hole through which the intruder got in (not to mention finding it). Due to the nature of such organizations, they are naturally more confident in their security obtained from their closeness than prepared for such breaches. That sounds logical. Yet, one cannot claim that the openness of OSS is just and strictly an advantage. It's a different SW development approach that its structure has its inherited *possible* weaknesses. Identifying and arranging for such incidents in the structure of the development process is what makes this model safe, and indeed, this case is an example of such a "preparation" and successful execution. In terms of OSS public relations there are two important thigns here: A. indeed, the openness brings its own "issues" (not to say, problems) that needs to be admitted, not quickly silenced (but of course to supplemented with the complimenting answer -> see B). Such breaches can be easily performed within close source organization, and must have already happened - *but surely not so easily admitted*. B. Yet, arranging for these issues makes the security of the OSS model at least as good, if not better, than closed source SW, exactly as demonstrated by this real world case and the letters in this thread demonstrated similar breaches within closed source organization and *their* consequences. In short - there is a weak point in the openness model. it is greatly acknowledged and treated hence achieving a better security model. Don't be impressed by the publicity it gets - you just dont hear of such cases in closed source organizations. My point of view, at least. Boaz. Gilad Ben-Yossef wrote: Interesting message I got. Isn't that a demonstration of the *real* (no FUD) open source model security break points? Actually, you just pointed out one of Open Source scurity model greatest strenghts, no weaknesses. How come? Well, think about what happend here: someone managed to gain unlawfull access to a distribution point of Linux source code and altered the code to instroduce a back door. The fact the file changed was found out by an "sanity check" but the true nature of the change (being a backdoor) was understood when the altered code was inspected by the community. Now, what would have happend if this was a run of the mill closed source security firm? 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). The nature of the change would never be detected and the back door might never even corrected, assuming the sys admin "fix" woulb to ignore the error. 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". Gilad = 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]
Re: Fw: What's wrong with this code?
> Interesting message I got. > Isn't that a demonstration of the *real* (no FUD) open source model > security break points? Actually, you just pointed out one of Open Source scurity model greatest strenghts, no weaknesses. How come? Well, think about what happend here: someone managed to gain unlawfull access to a distribution point of Linux source code and altered the code to instroduce a back door. The fact the file changed was found out by an "sanity check" but the true nature of the change (being a backdoor) was understood when the altered code was inspected by the community. Now, what would have happend if this was a run of the mill closed source security firm? 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). The nature of the change would never be detected and the back door might never even corrected, assuming the sys admin "fix" woulb to ignore the error. 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". Gilad -- Gilad Ben-Yossef <[EMAIL PROTECTED]> Codefidence. A name you can trust (tm) http://www.codefidence.com "Half of one of my eyes is already open. I'm going to make coffee now..." -- Kathi 16:08:04 = 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]
Re: Fw: What's wrong with this code?
On Thursday 13 November 2003 08:57, Aviram Jenik wrote: > Without saying whether that's a "good" demonstration or a "bad" > demonstration, lets remember what the demonstration actually was. > - Someone broke into an account authorized of making changes to the kernel > source > - They than changed a line of code in the kernel source using that account > - This code was comitted to the source tree In the kernel incident discussed above, the code was never commited to the source tree. it was "checked-in" on a CVS snapshot server which is never used for commiting code into the real source tree and should never be used to build binary kernels. IMO, this incident proves that the kernel development model of Linux stands up to the test, the OSS model stands up to the test, Larry Mcvoy stands up to the test, BitKeeper stands up to the test, and CVS sucks nuts (not that it was a big surprise :-). Just my 2 agoroth -- Oded = 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]
Re: Fw: What's wrong with this code?
On Thursday 13 November 2003 01:28, Boaz Rymland wrote: > > Further more, don't get me wrong. I did not conclude my "verdict" on OSS > security from this simple demonstration of a weak point. Not at all. > Without going into details I think the opposite - I prefer openess over > obscurity, taking in mind the price we have to pay for defending against > OSS weak points such as the one demonstrated. > Without saying whether that's a "good" demonstration or a "bad" demonstration, lets remember what the demonstration actually was. - Someone broke into an account authorized of making changes to the kernel source - They than changed a line of code in the kernel source using that account - This code was comitted to the source tree - This was rejected because of inproper procedure, and also because it looked "suspicious" (the comments weren't filled in) - It was stopped at that point; there was never a snapshot of the kernel with that code, not to mention an official release The analogy to a commercial company is: - Someone breaks into an account that has access to the product CVS tree - That attacker changes the source to insert a Trojan - The break-in is detected, the offending code removes - Nobody ever hears about it - this stays within the company. The security hole is found and plugged and none of the company's customers are aware of this (almost) breach The difference is, you will never hear of the latter case, since it is solved within the company. Therefore there is no way to assess whether these situations appear more on OS projects than on commercial projects. BTW, when I say "never hear", I mean never hear officially. Rumours are always there, but nobody can be certain: http://www.securiteam.com/securitynews/6E00L2000E.html -- - Aviram = 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]
Re: Fw: What's wrong with this code?
On Thu, Nov 13, 2003 at 01:28:05AM +0200, Boaz Rymland wrote: > > > Stanislav Malyshev wrote: > > >BR>> Isn't that a demonstration of the *real* (no FUD) open source model > >BR>> security break points? > > > >Well, that looks like open source _strong_ point. If the same code was > >closed, what chance someone - except, of course, for original programmer > >and probably his associates - would notice that? If, say, Windows function > >GetProcessSomeObscureAttribute would get you administrator > >privilege for some combination of flags - what is a chance someone would > >ever discover that? > > > > You're defenitly right in your point - in OSS many more eyes see the > code and can spot potential malicious pieces quickly. But this was not > my initial point - and maybe I should have clarified it: > Open Source model allows many bad minds access to the code, planning and > inserting sofisticated/obfuscated pieces of code, that hopefully will go > unnotinced, at least for some time, and that will grant them > non-legitimate power. Such a method for gaining this power is not > possible for the public in closed source enviroments. This malicious act > is an option only for employees of the company creating the specific > piece of SW (well, or for anyone else with access to their source code). > This seems to me, a weak point in the OSS development model, probably a > point which should not go unnotinced, as I'm sure happening, as in fact > did not go unnoticed in that example. [ For the record: the case above did not serve as a test-case for detecting obsure bugs by multiple eyes. The suspicous piece of code was spotted by Larry McVoy because of some checksum mismatch. He didn't spot the "=" instead of "==" by himself, but the circumstances looked very suspicious so he immidietly removed this code and sounded the alarm ] Certainly not possible in a respctable OS. We all trust Microsoft, Sun, Apple, IBM and the rest to hire only trust-worthy programmers for system programming. We know that there's no chance in the world that they can one such programmer could leave a time bomb. I mean, if you can't trust them, who can you trust? (And while we're on the subject: RedHat is probably such a trustworthy company as well. I mean: for certain version they give yo their word that it has no easter eggs ;-) ) But then again, they don't have access to the source code of all the drivers. Suppose the nice display driver would give you root for a certain pixel combination? A network card driver also offers quite a few places for back doors. So this is not a weak point of the open-source development model, but of the distributed development model. To clarify this: Suppose I have plenty of money and patiantce, and I want to backdoor many computers. One possible method is to try to get a backdoor code somehow into a software distibution channel. I figure that it would be best that the code won't be exposed too long, because once I start using back-doored systems, there is a very good chancethat someone will figure out how they were trojaned. It would also be nice to minimize the time others would have the potential to view my code. A useful shortcut is the security updates mechanism. There are quite a few of them, actually. All I need to do is to find such a system that updates enough machines, and that I can somehow get my code into. Not very easy. But given enough money, time to wait for the next security fix and "will power" this is not unthinkable with debian. I'm not sure about other system. -- Tzafrir Cohen +---+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---+ = 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]
Re: Fw: What's wrong with this code?
Stanislav Malyshev wrote: BR>> Isn't that a demonstration of the *real* (no FUD) open source model BR>> security break points? Well, that looks like open source _strong_ point. If the same code was closed, what chance someone - except, of course, for original programmer and probably his associates - would notice that? If, say, Windows function GetProcessSomeObscureAttribute would get you administrator privilege for some combination of flags - what is a chance someone would ever discover that? You're defenitly right in your point - in OSS many more eyes see the code and can spot potential malicious pieces quickly. But this was not my initial point - and maybe I should have clarified it: Open Source model allows many bad minds access to the code, planning and inserting sofisticated/obfuscated pieces of code, that hopefully will go unnotinced, at least for some time, and that will grant them non-legitimate power. Such a method for gaining this power is not possible for the public in closed source enviroments. This malicious act is an option only for employees of the company creating the specific piece of SW (well, or for anyone else with access to their source code). This seems to me, a weak point in the OSS development model, probably a point which should not go unnotinced, as I'm sure happening, as in fact did not go unnoticed in that example. Further more, don't get me wrong. I did not conclude my "verdict" on OSS security from this simple demonstration of a weak point. Not at all. Without going into details I think the opposite - I prefer openess over obscurity, taking in mind the price we have to pay for defending against OSS weak points such as the one demonstrated. = 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]
Re: Fw: What's wrong with this code?
BR>> Isn't that a demonstration of the *real* (no FUD) open source model BR>> security break points? Well, that looks like open source _strong_ point. If the same code was closed, what chance someone - except, of course, for original programmer and probably his associates - would notice that? If, say, Windows function GetProcessSomeObscureAttribute would get you administrator privilege for some combination of flags - what is a chance someone would ever discover that? -- [EMAIL PROTECTED] \/ There shall be counsels taken Stanislav Malyshev /\ Stronger than Morgul-spells phone +972-66-524945/\ JRRT LotR. whois:!SM8333 = 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]
Fw: What's wrong with this code?
Interesting message I got. Isn't that a demonstration of the *real* (no FUD) open source model security break points? It seems to me that unfortunately, theoretically, there could be many exploits of this vulnerability (or am I wrong here?). Boaz. *START READING FROM THE END!* -Original Message- Subject: RE: What's wrong with this code? All- Thanks to everyone who responded. In all I received over ten responses and all of them were great. Everyone who responded found the 'bug' (I'll explain why bug is in quotes) in the code below which was: 'current->uid = 0' and should have been 'current->uid == 0' Basically everyone noted that since there was a missing '=' the if-statement would always return false and therefore never execute 'retval = -EINVAL'. Some responses caught the deeper problem which was that instead of checking if 'current->uid' equals zero (a comparison) the code actually sets 'current->uid' equal to zero (an assignment) when flags _WCLONE and _WALL are set. This obviously is not a good thing - the user sets two flags and becomes uid 0 (i.e. root)! So where did I get this code? Well, this code was recently found in the Linux kernel function 'sys_wait4'. No, it wasn't a coding mistake but rather an attempt to backdoor the Linux kernel. For more information see: http://www.securityfocus.com/news/7388 Since I received so many responses I'm considering doing a challenge like this either once or twice a month; Call it "Spot the Vulnerability". I'd probably make the challenges a bit harder (more code) and ask people to identify the problem, how to fix it, and how to detect it in software engineering. Does the list thing it's a worthwhile idea? -John Walton p.s. I made a similar mistake on my compilers program recently. It took me over two hours to find. Unfortunately, gcc doesn't warn on things like an assignment inside if-statements . -Original Message- Subject: What's wrong with this code? Folks- Here is a little bit of a challenge for you. Take a look at the code below and find what is wrong with it and why: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL; Note: "_WCLONE" and "_WALL" are flags you can pass the program. For those of you who have seen or heard about this already don't spoil it for everyone else . -John Walton. = 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]
