"No, they aren't. If your idea isn't worth your time and investment, it sure as hell isn't worth theirs."
First of all, as has been pointed out several times in this thread, I can't profit from the idea at all, only the company can. So arguing whether or not it is worth my time is just dumb. It is quite likely something that could increase the company's profits by 10% would not be worth it to me to give up my weekends for the next 6 months in an effort to pursue it, but certainly would be worth it for the company to invest some resources to allow me to pursue it while on the job.
"If they say no, you have a choice. Leave or stay. You can't take the exact idea with you, but you do get to keep your domain knowledge. Maybe you can recreate the idea somewhere else."
Oh no, you can't even do that. First, if you were to "recreate" it elsewhere, you would be sued as soon as your old boss found out. They own the idea, and since you specifically told them about it, they have grounds to sue. And furthermore, you can't take your domain knowledge with you, as most engineers have to sign non-compete agreements before they start work at an employer. As an example, look at the spat between Google and MS over Kai-Fu Lee.
"To my knowledge (accumulated from the popular press and talking to some folks at Apple in addition to being a shareholder) is that Apple makes almost nothing on the sale of the music itself, believing that the majority of the profits gained from media should go to the artists and producers themselves."
I don't mean to offend all the Apple fanboys (well, I sort of do), but they use the music they sell through iTunes to drive iPod sales. It is not some sort of altruistic mission to give the money back to the artists, but a corporate mission to get higher profits. The concept of loss leaders (selling something for a loss or possibly minuscule gain) is nothing new, especially with music being the loss leader. In fact, it was in an attempt to prevent that which caused the who MAP scandal you all were crying about a few years ago.
If Apple were truly an "advocate for the consumer", then they would drop their proprietary formats and allow their iTunes songs to be played by products other than their own. Of course they are no more likely to do that than MS will be likely to port MS Office to Linux. It is in Apple's vested interest to keep their monopoly (yes, I said the 'M' word, Microsoft isn't the only company it can apply to) over digital music players that can play songs from iTunes.
Penis envy? Well, if you can design a space probe with your penis, then maybe I do have a little envy, though thats not what most people use those things for (and feel free to make the obligatory joke about other types of probes)...
Were the Voyager space probes and other successful space engineering projects of the time immensely successful marvels of engineering? Of course, especially considering the technology that was available at the time. But are you seriously denying that the technology has not evolved since then, making those techniques used (as successful and impressive as they are) outmoded? Sure the Great Pyramids were marvels of engineering, but I certainly wouldn't claim their techniques were just as good as modern techniques.
I know this is off topic, but I have to complain anyways. Why on earth did you waste the time linking to the Wikipedia for "background information" on the Voyager space probes? The reliability of a community edited "encyclopedia" aside, do you really think we wouldn't be able to find those links ourselves had they not been part of the article? Do you really think the Wikipedia is so difficult to navigate that only you have the smarts to find those articles?
"When talking to customers, naturally one goes through marketing or whoever handles the customer. But what's wrong with them saying to a customer "we want to take you out to lunch and have one of our researchers talk to you about your concerns"?"
Having marketing carefully arrange meetings between customers and research and development is one thing. An engineer suddenly announcing to their boss that they are taking the day off to go bug customers (like you suggested they do) is completely different.
"And so far as being too busy with your current committments, talking with employees and customers is how you meet your current committments. It's part of the task. "
Sorry, most engineers already have plenty of development commitments and simply don't have time to develop entirely new ideas. If you are in denial of that fact, you are living in a fantasy world.
"I've seen lots of ideas that are low risk. They are way more common than you would think. "
Its not the ideas themselves that I am saying are risky, its investing the time and energy to fully develop those ideas in the first place.
"Researchers have usually spent many years in university, and that's how they often relate to the world - the mere generation of good ideas is sufficient and praise worthy."
What university did you go to? Writing a thesis generally involves much more than simply thinking up an idea...
"and researchers must do everything they can to turn those ideas into commercial successes."
So where do you think management comes in? Just giving researchers pats on the back? Is that where they are earning their 6 digit salaries? Again, if researchers could do everything themselves, they wouldn't work for you. They would have gone off and started their own company and made millions off their ideas without having to share with the rest of the company.
"If a researcher said to his/her boss "I'll be away from my desk today talking to the users or marketing to find out what the real problems are", few bosses would object."
Actually, virtually all would. First, most communications with the customer are done through specific channels, primarily to avoid pissing off the customer (most people would not like it if they got dozens of phone calls from random employees from a company they just bought something from), casting the product in a bad light (if you were to ask whether or not the slow load time of a piece of software was a problem, many customers who had never noticed it before would now start complaining) or giving them incorrect information (a slip of the tongue could give a customer the impression that a new feature is coming in the next version). Often if an employee were to track down and question a customer without permission, that would be grounds for dismissal.
Second, most developers in today's business environment are busy trying to meet existing business commitments, so the manager would not like them wasting their day chasing down potential benefits which causes them to miss their current commitments.
"Not always. Maybe their company has the same problems yours does. And even if they have done it, you should still do it."
What? I think you missed the point, so I'll restate what I said before. Investing in innovation is a risk. Sometimes it pays off, more often it doesn't. There is no magical innovation "easy button" which a company can press and suddenly get a new bright idea.
Every idea starts out as a half baked idea. It takes a lot of work to fully develop them, which is hard to do without support from management. If management expects their employees to magically present them with fully developed ideas and well done business analysis (prepared by people with likely no business school training) for them to simply bless, they are in for a disappointment.
I know plenty of people who come up with crappy ideas but who can market them effectively. In the best case scenarios, those ideas only waste the resources that were diverted to fund them. In the worst case scenarios, those ideas hurt everyone who were tricked or forced into embracing them. So yes, coming up with ideas is easy. Coming up with good ideas is hard.
"Of course, to make the above work, the researcher would have to get down and dirty and actually talk to the end users to find out about the real world."
Which they have no way of doing unless they are given support from management. Its easy to come up with an idea while sitting in your cubicle working on your day to day work, but to advance an idea requires time and commitment. If the company's "innovation policy" is just to have employees come up with viable ideas on top of their day to day job, of course they are not going to get the hard stuff done.
Or do you expect employees to develop and market innovative ideas on their own time without support from management? But if they could do that, why would be working for the company in the first place? Why wouldn't they go off and start their own company and become rich selling their invention on their own? Too often management seems to think their only duty to innovation is to give pep talks, write memos stressing the importance of innovation, and every once in a while fund a project or two. That is lip service. Real innovation requires real investment. It is a risk, but if you could easily gain market share without risk, don't you think your competitors would have already done that?
"What's more, this isn't some small difference in positions or skills. This isn't like signing up to do C coding and being asked to do C++. Or being asked to take on a little Perl coding on the side. This is being asked to do an entirely different job, which bears no relation to your prior job. That's like being an HR person, and being asked to go into finance."
You might want to go back and read the original question again. This is not a programmer being moved into a managerial job, this is someone with experience as an architect whose job is being transitioned into a "dual architect / managerial role". The most likely cause is that the bean counters determined they had to drop headcount and combined the two jobs with the former architect effectively picking up some managerial responsibilities. He wasn't being told to move out of his old field (and to be honest, the fact that the guy is asking questions on how to be a better manager indicates that deep down, he is actually enthusiastic to take the new responsibilities, regardless of your assertion that no one likes being a manager). If you are asked to take up some additional responsibilities in your job and you abruptly quit over it, even if those responsibilities are not directly related to what you were hired for, its not exactly going to look very good. Companies often have to change things around, and if you are too inflexible to go with that, you are not going to be a very good asset.
"I think you wasted your time. What's this stuff about a recommendation? I've had quite a few jobs, and have NEVER gotten a recommendation from my old employer. That's insane."
No, they are not a necessary requirement to find a new job, but that does not mean they don't help. Having your former manager tell your prospective manager that you were a great asset to their team makes a big impression, and its much more helpful to them than how many buzzwords you can list on your resume.
Sure, I could have probably found some crap job on monster or dice administrating a database or maintaining some LAMP server, but that would have been even worse than staying in my old job. You say you have changed companies "quite a few times" in your 10 year career, thats not exactly a ringing endorsement. Don't take this the wrong way, but if you have had to change jobs every few years over the past decade because the job you took ended up being crap, maybe there is a problem in your approach.
"Maybe you work in some weird industry where you need ex-boss recommendations to change jobs, and permission from your current employer to leave or else you're blacklisted. I know the aviation industry (especially helicopters) is exactly like this. I assure you that the engineering industry, which I work in, is not like that at all, and hasn't been for the 10 years I've been in it."
Well, no, its absolutely important if your goal is to merely move around internally within a company rather than quit and move away. Every manager I know will, when looking at an internal job application, first check with the previous manager. And yes, despite the reputation of the software industry being full of quiet people who are afraid to communicate, people in our industry actually do talk to each other, and engineers can get reputations, even outside of the company in which they work. Of course that is assuming that you are not staying below the radar in meaningless jobs.
"Luckily, this isn't Soviet Russia where you have no choice in your career, and the job market is pretty good for software developers. Because of this, a person's interest is absolutely important if you want them to actually stick around."
So what do you say in your next job interview when asked why you are leaving your old job? "They asked me to do something I didn't want to do, so I quit"? The job market isn't that good. I'm not saying that you should let your employer dictate your career and spend your life working jobs you hate; in fact I recently changed jobs because the work I was on in my old one wasn't what I was interested in (I had been moved there after a reorg). But I only moved after giving that job a chance and having a number of discussions on the subject with my manager. As a result, I got a good recommendation which resulted in a good next job. Had I just stormed out the minute I got transferred, I wouldn't have been nearly as lucky. For one thing, I would be effectively banned from moving within the company (there is a company wide policy that barring approval from your manager, you are supposed to have been in your current position for at least a year before seeking a transfer), and likely would have had trouble finding another job when it was revealed the only reason I left my old one is that I am picky about what I do. Being labeled a job hopper isn't a good way to advance your career. And working two years on one technology did not typecast me to that area, and had I been in danger of that, I had plenty of opportunities to expand my expertise while working at my old job.
And I have known people who have gone back from managerial jobs to technical jobs (especially those 'architect'-style jobs where you are not writing code, but still technically involved in the product). Plus in this scenario, the employee is not moving to a full time managerial job but is "being transitioned into a dual architect / managerial role".
Actually, in my experience, former technical people make good managers of software developers. They have the experience to know where you are coming from, and the technical competence to understand your product well enough that they will help its development, not hinder it. Someone who has an MBA but no knowledge of software engineering will make a horrible manager as they can bring no contributions to the team other than repeating buzzwords and pretending they know what their employees are talking about.
And as to what makes them think this guy has an interest in being a manager, what makes you think what he is interested in matters to the guys who made him manager? Sometimes you are given jobs you are not particularly interested in, that doesn't mean you should quit the next day.
Free legal music streaming sites have been for years here in the states, people just don't pay attention to them because they prefer to download songs from services that are somewhat less legal and they go out of business.
Uh, they were saying thats solar's big advantage over wind power, not oil. Here is the full quote you pulled that tidbit from:
Like wind power, solar energy is spotty, working at full capacity an average 20% to 30% of the time. Solar's big advantage is that it supplies the most electricity midday, when demand peaks.
Most commercially bought software has a support contract.
"What Stallman? Who mentioned anything about him? Can't you avoid having to resort to bringing up people who have nothing to do with the subject?"
Sure, but its fun making fun of the fact you are clearly a Stallman fanboy with no ability to think for yourself. Though its getting old now, and your 'arguments' seem to be more in the mold of denial.
"It's simple logic. All other things being equal (and they perfectly can be, because I'm not talking about any specific license here), the availability of source makes it much harder to sneak something nasty in. QED."
The very fact that you think quoting some "Open source is better, yeah!" rhetoric is a logically valid argument means its no more use arguing with you...
"That your claim that commercial software somehow provides some sort of guarantee."
I made no such claim, and no matter how long you spend looking back through this thread, you will find nothing proving I did. You merely think I did because you are incapable of seeing the world in anything but black and white, Ballmer vs Stallman, so you think anyone who doubts the magical powers of OSS must be in cahoots with MS. Unfortunately that just makes you look like a fool when it turns out the world is not like it.
"You imply that when you say "Virtually every piece of commercial software has to be supported, which means you have to have a support staff looking at the code. [...]""
It implies nothing of the sort, but good use of your imagination (or poor reading comprehension skills).
"When programmers are the support staff they can do whatever they please. If they put a trojan in, there's not going to be anybody over them watching."
Except the support contract doesn't end when the programmer leaves his job. In order for that scheme to work, the programmer would be risking his freedom and economic security on never losing his job and never moving to a different position. The fact of the matter is, even in a closed source project, you have no way of ensuring no one else will look at your code. But once again, this is entirely irrelevant (other than it indicates your problems understanding common sense).
"Just like every piece of software in existence. Maybe with the rare exception of custom contracted coding, but that's not what we're talking about here."
Wow, then why did I waste all that time helping support debug our product (which wasn't "custom contracted coding", btw)? Sorry, you are wrong again.
"Disagree, it's neutral. Anybody can write software. Neither closed nor open source is inherently harder to write or publish. Possibility of collaboration isn't very relevant, I can work with somebody on a closed but free of charge program, or publish OSS and not accept anybody's patches."
<sarcasm>Whatever you say Mr. Stallman</sarcasm>. So the question is, do you think this because you are blinded by ideology, or the other reason?
"
Nothing at all is stopping me from becoming an 1 employee company and selling software. That doesn't confer any magical safety benefits for the end users.
There are programs in wide use (especially shareware) made by a team of 1-3 people. File compression tools for instance. Moonpod, a company that sells games online has 2 employees. They manage fine."
And there are many more such OSS projects. Whats your point?
"Right, and I can do that with a closed source app as well. Only it'll take more time to figure out what it does, and I can connect to a wireless AP once, upload by trojan to a bunch of download sites, then never appear again."
Aside from the fact that whether or not you can hack commercial software is irrelevant to the point we are discussing (whether or not open source software is immune to such attacks), name one commercial company that allows anonymous contributers to their proprietary software.
"No, you are the one thinking that incorporation somehow confers magical safety benefits."
I absolutely did not say anything remotely like that. Please work on your reading comprehension skills.
Look, I really don't know how much more clear I can make this without writing in "See Spot Run" style. Both proprietary and open source software have their advantages and their disadvantages. And all the Stallmans and Ballers of the world who try to argue otherwise are either blinded by ideology to the point where they are incapable of using common sense or complete fucking retards. Open source obviously has the advantage in that it is easier for third parties or users (in the rare cases where they have the knowledge and time) to verify what the program does. But it also has disadvantages in that it is easier for someone dishonest or unskilled to participate in them, and there isn't anyone to hold accountable when a problem occurs (they are generally provided as-is without any guarantees).
So if you are thinking either one is superior in every way, you are an idiot. And if you are thinking either one is so perfect that you don't have to take any precautions at all (like using AppArmor; in case your attention span is so pathetic you forgot what we were arguing about, it was the remark that you only have to take such precautions when you have closed source applications on your system), you are a complete retard.
There, I had to resort to name calling. Did that make it clear for you? Or are you still unable to comprehend that there is more to the world than the party lines preached by the Ballers and Stallmans of the world?
"All normal people I've seen have lots of third party software. The most computer illiterate person I know has installed a music score editor, and seems to have filled the disk with stuff downloaded from kaazaa, at the very least. Certainly there's a lot more than that there, but I didn't investigate."
Once again, your acquaintances are not representative of the population as a whole. For every college student you know who installs a ton of crap on their computer, there are plenty who just use theirs for basic communication, browsing the net, and maybe writing a Word doc.
"Oh, it isn't."
Then it is irrelevant to the discussion at hand. We are talking about people who deliberately insert vulnerabilities into software that is then sold to others, not people who hack into their own corporate networks.
"But you seriously overestimate the level of control going on in places. While I'd completely agree such a thing would be bad management, I'm pretty sure it happens quite a lot, too."
And from what experience are you making this claim?
Virtually every piece of commercial software has to be supported, which means you have to have a support staff looking at the code. These guys will often find any vulnerabilities you left (debugging the software is kind of their job), and even the most rudimentary form of source control will have a way to determine who put in what code.
"Those albums are effectively free to Sony. "
Contrary to popular belief, Sony being forced to give away the product they usually sell for $10-$15 each costs them a lot of money. And of course you are forgetting they have to recall all existing rootkit CDs, which is always expensive. Again, the results of class action lawsuits never look great from the perspective of the individuals participating in the suit, but companies are hurt by them.
"Ok, if he's so anonymous, how did people to get to use his software in the first place? Generally distributions don't include software without an active and reachable developer. If you have a website, domain, email address, etc, you're reasonably easy to trace."
Trust me, its perfectly possible to set that up and be anonymous. Just because you can't doesn't mean someone with some reasonable level of technical skill can't. Yes, many OSS projects ensure they have enough information that they know who you are, but certainly not all. Its not hard to set up a sourceforge account with a free untraceable address from someone like gmail that you then only access from someone's open wireless network.
"Not the point anyway. The point is to discourage bad behavior, and you can discourage a single person a lot more effectively than a corporation."
So you can more easily discourage an individual who can easily remain anonymous and who might not have any assets and thus be willing to risk it all if they did somehow get caught than you can a large corporation who you can file a class action lawsuit against? I think you are in denial.
"Nope. Consider the ongoing discussion about Microsoft Vista and an apparent network slow down while playing music. The question of what's happening would be settled quickly by a code audit, except that no one outside of Microsoft is able to do that."
<sarcasm>Right, because code audits are always perfect and catch every flaw in existence. Thats why open source software is always bug free.</sarcasm>
Look, I'm not arguing that OSS has no advantages. Of course it does. But it also has its share of disadvantages, even if the Richard Stallman and his zealots refuse to believe it.
"What you say might apply to people who only very ocassionally use a computer for printing something, but those wouldn't be what I call normal users, just like I wouldn't call somebody who gets out their bycicle out once a year a cyclist."
Ok, but if you want to be all elitist and dictate who is a computer user and who is not, why not go all the way and rule out all Windows users? Those who use their computers for only a few functions make up a large number of computer users, probably the majority. In fact, nowadays even I don't use my home computer for much more than browsing the Internet and reading my email, as I spend so much time on my work computer I don't want to do much more when I get home. Granted back in college I used it for a lot more, but college students make up a minority of all computer users.
"No, the company is simply small and doesn't concentrate on development. I double as the sysadmin. That's all the IT staff (me)."
If your company is selling software (otherwise it would irrelevant to the point) and you are the entire IT staff, then your company probably has problems.
"Vulnerabilities? I don't remember MS being ever sued for that, and they've had plenty."
I should have been more clear. Intentional vulnerabilities will result in lawsuits.
"Yes, because people got a pile of money from Sony. Let's see, the settlement was: "Customers who exchange their XCP CD can either download three albums from a list of over 200 titles, or claim a cash payment of $7.50 and a free download of one album"."
Times a lot of customers.
"In comparison, if this was a normal person and not a multinational, you'd have the guy bankrupt for the rest of his life. While I imagine you wouldn't get a whole lot out of it, I imagine you could get more than $7.5, and the result for the offending party would look a lot more like a punishment."
First, you are assuming you can catch him, which is unlikely if he is an anonymous OSS developer. Second, that isn't how bankruptcy works. It is perfectly possible for someone to recover from bankruptcy. Third, it doesn't matter if the other party is a multinational or an individual, class action lawsuits don't return that much to each person in the suit.
In other words, you wouldn't get a penny if this was an individual. So take your $7.50 and consider yourself lucky.
Very few freeware applications are as widely used as the Linux kernel, either. So if thats the scope of the vulnerability you are seeking, neither is really a good way to achieve it. But the smaller attacks that only effect a few systems can still be dangerous. And some of those smaller open source apps can be pretty common. Consider something like gaim/pidgin. It is a relatively small project, and I believe much of it was developed by students. Yet it is used by a lot of people, and it has had security issues in the past.
"
There's a difference of scale.
In the first case you have a developer who wrote the whole thing, got found out, and inexplicably managed to convince somebody to stay silent. This developer has the size on their side, because the chances of that people won't look very well at a 50K line program is much greater than that something will be missed in a 10 line patch."
Fine, swap my example of a developer giving a patch with one starting their own project if it concerns you so much. My argument will be just as valid. The distinction is a red herring.
"You've not dealt with enough Windows users, I see. Most of them seem to install any crap they can find anywhere. "
No offense, but the Windows users you know are not representative of the community as a whole. Many just use whatever they are given, and don't bother installing anything else unless they absolutely need it. If Windows users were always prone to download any app they could find, why would the EU be concerned about what software MS pre-installs on their OS?
"That's not my point, my point is that while the Debian maintainer might not read all of firefox, the Red Hat one is probably not looking at exactly the same parts source."
And if the vulnerability only makes it in one or two distros? Your argument is contingent on it being widespread. But thats not always the case.
"No, but this is prefectly possible for a distribution to do. End users shouldn't be compiling anyway. The distribution making sure their toolchain is good is enough."
Once again, this assumes the software comes from a distro, which we have already established is not always the case. And even then, I'm sure distro owners don't do this for every package and every patch they include.
"Uh huh. I work at a company (working on internal code though). I could put any crap I wanted there, and probably nobody would ever find out, because nobody else at the company is capable of reading the simplest code."
Ok, your company sucks (either that or you are an arrogant prick who thinks all his coworkers can't do a thing when in reality they are just as capable as yourself). Whats your point? There are plenty of open source projects where the developers miss things as well (as I illustrated in my last post).
"You can't even boycott them because you're not their customer -- they sell their crap to somebody else."
Boycotts are for sissies. If a commercial software program is found with a vulnerability, they will be the subject of a lawsuit. And then they will go back and check the records to see who inserted that code, and you will be caught red handed.
"Besides, there are no real consequences for a company. Sony got off very, very lightly for what they did. Did anybody go to jail? Of course not."
Sony is currently facing class action lawsuits against them for rootkit incident. And they did get a lot of bad press, which certainly hurt their sales. The lack of criminal prosecution (so far) doesn't mean they got off cleanly.
In comparison, a hacker who submitted a patch or started a project anonymously with such a vulnerability could get off without a scratch. And even if he did get caught, its highly unlikely that he would have the assets for you to sue him and recover any damages.
"Ok, if you're so clever, provide an example of code that reads a file without making it easy to tell what it's doing, while avoiding looking suspicious."
First, I never said I was a hacker, so this really isn't my area of expertise. But as to how I would probably go about it if I were...
First, the actual reading of the file would be done by some existing code that processing needed files, so I wouldn't be adding any obvious code that opens files. And it would probably have to log the contents it is processing if an error occurred (so the evil software would then be able to do something with it. Then when I passed in the file it is not supposed to access, I would probably use some sort of generated regular expression that could (on certain inputs) match extra files (including whatever I want it to read). Then since those are not considered valid methods, it would encounter an error and logs the contents it was processing.
But again, this is not my area of expertise. I'm sure someone more experienced in this type of work could do a much better job.
"Don't change subject. The original post was about a developer releasing "evil" code, then turning somebody who finds it to their side. Now you're talking about people submitting patches with somethind hidden in them. Completely different scenarios."
Doesn't matter if it is the submitter of a random patch or the original developer. Either one could be anonymous. Yes, I am aware that is not the case with most large OSS projects, but they are not the ones I am worried about.
"Stupidity exist everywhere of course, can't be eliminated 100%. But while for Linux users perhaps 1% of all software comes from unverified sources, for Windows users it's 99%."
I don't know the statistics here, but I'm guessing most Windows users don't install that much (intentionally, at least) that doesn't come with the computer.
"Not all of it, but there are many distributions, which each look at different parts of the source. To sneak something in you'd need to be really sure that part won't get looked at by anybody, and that's hard. Developers watch mailing lists, talk to people who work on the project and use 'svn diff'."
It doesn't need to go in all distributions, just one or two. And it doesn't need to go in the official stable version for people to install it, many people use bleeding edge versions of distros.
"
First you build gcc with icc. This is icc_gcc.
Then you build another copy of gcc with gcc. This is gcc_gcc.
Now you have two gccs with different code generated by different compilers.
So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy.
You can easily this with more compilers and multiple versions."
"Easily" is obviously a relative term. Are you really suggesting people do this with all their open source software, all so they can avoid running something like AppArmor?
"Well, I still think it can't be defined that the OSS approach is superior. It's not impossible to sneak something in. But in doing so you must take a very high risk of being found out, and if somebody tracks that back to you, well, chances are you're going to have to look for a new carreer. People with a known record of coding nasty things aren't very liked in the software world."
Yes, there certainly are advantages to OSS, but thats not one. I'm fairly certain your chances of having your vulnerability being caught AND it being traced back to you are much greater when you put it in as an employee of a software company as opposed to an anonymous developer of a OSS project.
The whole question of whether or not its possible to sneak in a vulnerability is moot, as I have personally seen it happen. The application (I won't name it, as they did fix the problem) would allow (under default settings, with a certain add on installed) an attacker to execute
"But you're admitting that it is not guaranteed? "rare" != "never"."
Of course. I never said commercial software is guaranteed to be perfect. That obviously isn't the case.
"You have only your faith in the company who wrote the code that it was properly reviewed and audited prior to release."
Just as you have only your faith in the open source community that it was properly reviewed and audited prior to release. Remember, I'm not arguing that commercial software is inherently better than open source, only that it is not inherently worse. Both have their shares of advantages and disadvantages.
"The difference with open source is that while you may take it on faith that the code has been reviewed, you have the opportunity to do it yourself..."
Only if you have both the ability and time to do so. Most people don't.
"...or pay someone to do it for you. "
Thats exactly what you are doing when you purchase commercial software. Yes, sometimes the people you are paying do a crappy job, but that can happen with the people you hire to work on the open source as well.
"This sort of "evil" is very transparent. You can code a hidden buffer overflow/exploit/backdoor in such a way that it's not obvious (= instead of == for example, caught in the Linux kernel once). But how do you hide an access to say,/proc/interrupts? You need to spell out the filename, and there's got to be an open or fopen for it somewhere. Any attempt to encode the filename is going to be weird and suspicious. Plus, file parsing would be quite a bit than a single line of code, so it's hard not to notice something is being read, stored, etc."
Would it be difficult? Sure. But if you think it is impossible to hide an access to a file you are not supposed to see, you are obviously either new to writing software, or you lack imagination.
"Uh huh. Such a thing would be an outright admission of evildoing. Depending on what is being done it might be enough for a lawsuit, and definitely enough for mass publication all over the web to ruin the developer's name."
Thats an example of why such activities should be rare in the commercial world, where the developer's name, address, social security number, etc., are all on record. But not in the world of many open source projects where it is perfectly possible for someone to be practically anonymous when they submit their patches.
"But 99% of Linux software is delivered by the distribution, with the package maintainer often being completely unrelated to the developer."
Considering how many software packages a person typically has installed on their machine, that extra 1% is pretty dangerous. Yes, the official packages you got straight from the distro may all be fine, what about that new upgrade you went to that great new rpm repository your buddy told you about?
"You can bet that eg, the Debian maintainer of Firefox looked at the source."
You honestly think the owners of the distros look at all the source of each package they include? You must think they have no lives whatsoever.
"That's a tricky one, but you can use a different compiler."
I fail to see how that helps. How do you know the different compiler isn't the one with the Trojan? Its like if we were picking apples from a tree and I point out you have no way of knowing the one you just picked hasn't been poisoned, you throw that apple away and pick another one.
"It's easy to make a compiler that hiddenly changes some well known part of the source, but it's much harder to deal with a complete reorganization of it. To keep it up would need updates to the evil compiler."
It only needs to get in there once. And besides, I really don't think it would be that difficult to insert something generic like a keystroke monitor that would effect pretty much anything compiled with it.
"If Skype was open source we wouldn't be having this discussion at all."
I don't doubt that at all. A problem with an open source program rarely is treated the same as a problem with a commercial app by/. But that says more about the/. culture than it does the differences between open source and closed source.
I'm not saying don't use open source software. Just don't pretend it is immune to the problems that plague commercial software and forget about all precautions (like not running something like AppArmor, to tie this back to the original point) just because what you are running is under the GPL.
First of all, it is rare that only one person reads the source for any commercial software product. Code reviews are standard in most organizations, and even if not, there are many developers at work maintaining that code.
Second, with open source apps, you really don't know that. It is perfectly possible for someone to submit a bad patch and no one bothers to really look at it in depth (at least not as in depth as you would need to catch a well disguised security breach). A lot of people use software assuming someone else has audited it and made sure there is nothing wrong with it solely because it is under the GPL. But that is a very bad assumption to make.
Slashdot Mirror
"No, they aren't. If your idea isn't worth your time and investment, it sure as hell isn't worth theirs."
First of all, as has been pointed out several times in this thread, I can't profit from the idea at all, only the company can. So arguing whether or not it is worth my time is just dumb. It is quite likely something that could increase the company's profits by 10% would not be worth it to me to give up my weekends for the next 6 months in an effort to pursue it, but certainly would be worth it for the company to invest some resources to allow me to pursue it while on the job.
"If they say no, you have a choice. Leave or stay. You can't take the exact idea with you, but you do get to keep your domain knowledge. Maybe you can recreate the idea somewhere else."
Oh no, you can't even do that. First, if you were to "recreate" it elsewhere, you would be sued as soon as your old boss found out. They own the idea, and since you specifically told them about it, they have grounds to sue. And furthermore, you can't take your domain knowledge with you, as most engineers have to sign non-compete agreements before they start work at an employer. As an example, look at the spat between Google and MS over Kai-Fu Lee.
"To my knowledge (accumulated from the popular press and talking to some folks at Apple in addition to being a shareholder) is that Apple makes almost nothing on the sale of the music itself, believing that the majority of the profits gained from media should go to the artists and producers themselves."
I don't mean to offend all the Apple fanboys (well, I sort of do), but they use the music they sell through iTunes to drive iPod sales. It is not some sort of altruistic mission to give the money back to the artists, but a corporate mission to get higher profits. The concept of loss leaders (selling something for a loss or possibly minuscule gain) is nothing new, especially with music being the loss leader. In fact, it was in an attempt to prevent that which caused the who MAP scandal you all were crying about a few years ago.
If Apple were truly an "advocate for the consumer", then they would drop their proprietary formats and allow their iTunes songs to be played by products other than their own. Of course they are no more likely to do that than MS will be likely to port MS Office to Linux. It is in Apple's vested interest to keep their monopoly (yes, I said the 'M' word, Microsoft isn't the only company it can apply to) over digital music players that can play songs from iTunes.
Penis envy? Well, if you can design a space probe with your penis, then maybe I do have a little envy, though thats not what most people use those things for (and feel free to make the obligatory joke about other types of probes)...
Were the Voyager space probes and other successful space engineering projects of the time immensely successful marvels of engineering? Of course, especially considering the technology that was available at the time. But are you seriously denying that the technology has not evolved since then, making those techniques used (as successful and impressive as they are) outmoded? Sure the Great Pyramids were marvels of engineering, but I certainly wouldn't claim their techniques were just as good as modern techniques.
I know this is off topic, but I have to complain anyways. Why on earth did you waste the time linking to the Wikipedia for "background information" on the Voyager space probes? The reliability of a community edited "encyclopedia" aside, do you really think we wouldn't be able to find those links ourselves had they not been part of the article? Do you really think the Wikipedia is so difficult to navigate that only you have the smarts to find those articles?
"When talking to customers, naturally one goes through marketing or whoever handles the customer. But what's wrong with them saying to a customer "we want to take you out to lunch and have one of our researchers talk to you about your concerns"?"
Having marketing carefully arrange meetings between customers and research and development is one thing. An engineer suddenly announcing to their boss that they are taking the day off to go bug customers (like you suggested they do) is completely different.
"And so far as being too busy with your current committments, talking with employees and customers is how you meet your current committments. It's part of the task. "
Sorry, most engineers already have plenty of development commitments and simply don't have time to develop entirely new ideas. If you are in denial of that fact, you are living in a fantasy world.
"I've seen lots of ideas that are low risk. They are way more common than you would think. "
Its not the ideas themselves that I am saying are risky, its investing the time and energy to fully develop those ideas in the first place.
"Researchers have usually spent many years in university, and that's how they often relate to the world - the mere generation of good ideas is sufficient and praise worthy."
What university did you go to? Writing a thesis generally involves much more than simply thinking up an idea...
"and researchers must do everything they can to turn those ideas into commercial successes."
So where do you think management comes in? Just giving researchers pats on the back? Is that where they are earning their 6 digit salaries? Again, if researchers could do everything themselves, they wouldn't work for you. They would have gone off and started their own company and made millions off their ideas without having to share with the rest of the company.
"If a researcher said to his/her boss "I'll be away from my desk today talking to the users or marketing to find out what the real problems are", few bosses would object."
Actually, virtually all would. First, most communications with the customer are done through specific channels, primarily to avoid pissing off the customer (most people would not like it if they got dozens of phone calls from random employees from a company they just bought something from), casting the product in a bad light (if you were to ask whether or not the slow load time of a piece of software was a problem, many customers who had never noticed it before would now start complaining) or giving them incorrect information (a slip of the tongue could give a customer the impression that a new feature is coming in the next version). Often if an employee were to track down and question a customer without permission, that would be grounds for dismissal.
Second, most developers in today's business environment are busy trying to meet existing business commitments, so the manager would not like them wasting their day chasing down potential benefits which causes them to miss their current commitments.
"Not always. Maybe their company has the same problems yours does. And even if they have done it, you should still do it."
What? I think you missed the point, so I'll restate what I said before. Investing in innovation is a risk. Sometimes it pays off, more often it doesn't. There is no magical innovation "easy button" which a company can press and suddenly get a new bright idea.
Every idea starts out as a half baked idea. It takes a lot of work to fully develop them, which is hard to do without support from management. If management expects their employees to magically present them with fully developed ideas and well done business analysis (prepared by people with likely no business school training) for them to simply bless, they are in for a disappointment.
"Ideas are - in some ways - the easy part."
I know plenty of people who come up with crappy ideas but who can market them effectively. In the best case scenarios, those ideas only waste the resources that were diverted to fund them. In the worst case scenarios, those ideas hurt everyone who were tricked or forced into embracing them. So yes, coming up with ideas is easy. Coming up with good ideas is hard.
"Of course, to make the above work, the researcher would have to get down and dirty and actually talk to the end users to find out about the real world."
Which they have no way of doing unless they are given support from management. Its easy to come up with an idea while sitting in your cubicle working on your day to day work, but to advance an idea requires time and commitment. If the company's "innovation policy" is just to have employees come up with viable ideas on top of their day to day job, of course they are not going to get the hard stuff done.
Or do you expect employees to develop and market innovative ideas on their own time without support from management? But if they could do that, why would be working for the company in the first place? Why wouldn't they go off and start their own company and become rich selling their invention on their own? Too often management seems to think their only duty to innovation is to give pep talks, write memos stressing the importance of innovation, and every once in a while fund a project or two. That is lip service. Real innovation requires real investment. It is a risk, but if you could easily gain market share without risk, don't you think your competitors would have already done that?
"What's more, this isn't some small difference in positions or skills. This isn't like signing up to do C coding and being asked to do C++. Or being asked to take on a little Perl coding on the side. This is being asked to do an entirely different job, which bears no relation to your prior job. That's like being an HR person, and being asked to go into finance."
You might want to go back and read the original question again. This is not a programmer being moved into a managerial job, this is someone with experience as an architect whose job is being transitioned into a "dual architect / managerial role". The most likely cause is that the bean counters determined they had to drop headcount and combined the two jobs with the former architect effectively picking up some managerial responsibilities. He wasn't being told to move out of his old field (and to be honest, the fact that the guy is asking questions on how to be a better manager indicates that deep down, he is actually enthusiastic to take the new responsibilities, regardless of your assertion that no one likes being a manager). If you are asked to take up some additional responsibilities in your job and you abruptly quit over it, even if those responsibilities are not directly related to what you were hired for, its not exactly going to look very good. Companies often have to change things around, and if you are too inflexible to go with that, you are not going to be a very good asset.
"I think you wasted your time. What's this stuff about a recommendation? I've had quite a few jobs, and have NEVER gotten a recommendation from my old employer. That's insane."
No, they are not a necessary requirement to find a new job, but that does not mean they don't help. Having your former manager tell your prospective manager that you were a great asset to their team makes a big impression, and its much more helpful to them than how many buzzwords you can list on your resume.
Sure, I could have probably found some crap job on monster or dice administrating a database or maintaining some LAMP server, but that would have been even worse than staying in my old job. You say you have changed companies "quite a few times" in your 10 year career, thats not exactly a ringing endorsement. Don't take this the wrong way, but if you have had to change jobs every few years over the past decade because the job you took ended up being crap, maybe there is a problem in your approach.
"Maybe you work in some weird industry where you need ex-boss recommendations to change jobs, and permission from your current employer to leave or else you're blacklisted. I know the aviation industry (especially helicopters) is exactly like this. I assure you that the engineering industry, which I work in, is not like that at all, and hasn't been for the 10 years I've been in it."
Well, no, its absolutely important if your goal is to merely move around internally within a company rather than quit and move away. Every manager I know will, when looking at an internal job application, first check with the previous manager. And yes, despite the reputation of the software industry being full of quiet people who are afraid to communicate, people in our industry actually do talk to each other, and engineers can get reputations, even outside of the company in which they work. Of course that is assuming that you are not staying below the radar in meaningless jobs.
"Luckily, this isn't Soviet Russia where you have no choice in your career, and the job market is pretty good for software developers. Because of this, a person's interest is absolutely important if you want them to actually stick around."
So what do you say in your next job interview when asked why you are leaving your old job? "They asked me to do something I didn't want to do, so I quit"? The job market isn't that good. I'm not saying that you should let your employer dictate your career and spend your life working jobs you hate; in fact I recently changed jobs because the work I was on in my old one wasn't what I was interested in (I had been moved there after a reorg). But I only moved after giving that job a chance and having a number of discussions on the subject with my manager. As a result, I got a good recommendation which resulted in a good next job. Had I just stormed out the minute I got transferred, I wouldn't have been nearly as lucky. For one thing, I would be effectively banned from moving within the company (there is a company wide policy that barring approval from your manager, you are supposed to have been in your current position for at least a year before seeking a transfer), and likely would have had trouble finding another job when it was revealed the only reason I left my old one is that I am picky about what I do. Being labeled a job hopper isn't a good way to advance your career. And working two years on one technology did not typecast me to that area, and had I been in danger of that, I had plenty of opportunities to expand my expertise while working at my old job.
And I have known people who have gone back from managerial jobs to technical jobs (especially those 'architect'-style jobs where you are not writing code, but still technically involved in the product). Plus in this scenario, the employee is not moving to a full time managerial job but is "being transitioned into a dual architect / managerial role".
Actually, in my experience, former technical people make good managers of software developers. They have the experience to know where you are coming from, and the technical competence to understand your product well enough that they will help its development, not hinder it. Someone who has an MBA but no knowledge of software engineering will make a horrible manager as they can bring no contributions to the team other than repeating buzzwords and pretending they know what their employees are talking about.
And as to what makes them think this guy has an interest in being a manager, what makes you think what he is interested in matters to the guys who made him manager? Sometimes you are given jobs you are not particularly interested in, that doesn't mean you should quit the next day.
Free legal music streaming sites have been for years here in the states, people just don't pay attention to them because they prefer to download songs from services that are somewhat less legal and they go out of business.
"Dude, what support contract? "
Most commercially bought software has a support contract.
"What Stallman? Who mentioned anything about him? Can't you avoid having to resort to bringing up people who have nothing to do with the subject?"
Sure, but its fun making fun of the fact you are clearly a Stallman fanboy with no ability to think for yourself. Though its getting old now, and your 'arguments' seem to be more in the mold of denial.
"It's simple logic. All other things being equal (and they perfectly can be, because I'm not talking about any specific license here), the availability of source makes it much harder to sneak something nasty in. QED."
The very fact that you think quoting some "Open source is better, yeah!" rhetoric is a logically valid argument means its no more use arguing with you...
"That your claim that commercial software somehow provides some sort of guarantee."
I made no such claim, and no matter how long you spend looking back through this thread, you will find nothing proving I did. You merely think I did because you are incapable of seeing the world in anything but black and white, Ballmer vs Stallman, so you think anyone who doubts the magical powers of OSS must be in cahoots with MS. Unfortunately that just makes you look like a fool when it turns out the world is not like it.
"You imply that when you say "Virtually every piece of commercial software has to be supported, which means you have to have a support staff looking at the code. [...]""
It implies nothing of the sort, but good use of your imagination (or poor reading comprehension skills).
"When programmers are the support staff they can do whatever they please. If they put a trojan in, there's not going to be anybody over them watching."
Except the support contract doesn't end when the programmer leaves his job. In order for that scheme to work, the programmer would be risking his freedom and economic security on never losing his job and never moving to a different position. The fact of the matter is, even in a closed source project, you have no way of ensuring no one else will look at your code. But once again, this is entirely irrelevant (other than it indicates your problems understanding common sense).
"Just like every piece of software in existence. Maybe with the rare exception of custom contracted coding, but that's not what we're talking about here."
Wow, then why did I waste all that time helping support debug our product (which wasn't "custom contracted coding", btw)? Sorry, you are wrong again.
"Disagree, it's neutral. Anybody can write software. Neither closed nor open source is inherently harder to write or publish. Possibility of collaboration isn't very relevant, I can work with somebody on a closed but free of charge program, or publish OSS and not accept anybody's patches."
<sarcasm>Whatever you say Mr. Stallman</sarcasm>. So the question is, do you think this because you are blinded by ideology, or the other reason?
" Nothing at all is stopping me from becoming an 1 employee company and selling software. That doesn't confer any magical safety benefits for the end users. There are programs in wide use (especially shareware) made by a team of 1-3 people. File compression tools for instance. Moonpod, a company that sells games online has 2 employees. They manage fine."
And there are many more such OSS projects. Whats your point?
"Right, and I can do that with a closed source app as well. Only it'll take more time to figure out what it does, and I can connect to a wireless AP once, upload by trojan to a bunch of download sites, then never appear again."
Aside from the fact that whether or not you can hack commercial software is irrelevant to the point we are discussing (whether or not open source software is immune to such attacks), name one commercial company that allows anonymous contributers to their proprietary software.
"No, you are the one thinking that incorporation somehow confers magical safety benefits."
I absolutely did not say anything remotely like that. Please work on your reading comprehension skills.
Look, I really don't know how much more clear I can make this without writing in "See Spot Run" style. Both proprietary and open source software have their advantages and their disadvantages. And all the Stallmans and Ballers of the world who try to argue otherwise are either blinded by ideology to the point where they are incapable of using common sense or complete fucking retards. Open source obviously has the advantage in that it is easier for third parties or users (in the rare cases where they have the knowledge and time) to verify what the program does. But it also has disadvantages in that it is easier for someone dishonest or unskilled to participate in them, and there isn't anyone to hold accountable when a problem occurs (they are generally provided as-is without any guarantees).
So if you are thinking either one is superior in every way, you are an idiot. And if you are thinking either one is so perfect that you don't have to take any precautions at all (like using AppArmor; in case your attention span is so pathetic you forgot what we were arguing about, it was the remark that you only have to take such precautions when you have closed source applications on your system), you are a complete retard.
There, I had to resort to name calling. Did that make it clear for you? Or are you still unable to comprehend that there is more to the world than the party lines preached by the Ballers and Stallmans of the world?
"All normal people I've seen have lots of third party software. The most computer illiterate person I know has installed a music score editor, and seems to have filled the disk with stuff downloaded from kaazaa, at the very least. Certainly there's a lot more than that there, but I didn't investigate."
Once again, your acquaintances are not representative of the population as a whole. For every college student you know who installs a ton of crap on their computer, there are plenty who just use theirs for basic communication, browsing the net, and maybe writing a Word doc.
"Oh, it isn't."
Then it is irrelevant to the discussion at hand. We are talking about people who deliberately insert vulnerabilities into software that is then sold to others, not people who hack into their own corporate networks.
"But you seriously overestimate the level of control going on in places. While I'd completely agree such a thing would be bad management, I'm pretty sure it happens quite a lot, too."
And from what experience are you making this claim?
Virtually every piece of commercial software has to be supported, which means you have to have a support staff looking at the code. These guys will often find any vulnerabilities you left (debugging the software is kind of their job), and even the most rudimentary form of source control will have a way to determine who put in what code.
"Those albums are effectively free to Sony. "
Contrary to popular belief, Sony being forced to give away the product they usually sell for $10-$15 each costs them a lot of money. And of course you are forgetting they have to recall all existing rootkit CDs, which is always expensive. Again, the results of class action lawsuits never look great from the perspective of the individuals participating in the suit, but companies are hurt by them.
"Ok, if he's so anonymous, how did people to get to use his software in the first place? Generally distributions don't include software without an active and reachable developer. If you have a website, domain, email address, etc, you're reasonably easy to trace."
Trust me, its perfectly possible to set that up and be anonymous. Just because you can't doesn't mean someone with some reasonable level of technical skill can't. Yes, many OSS projects ensure they have enough information that they know who you are, but certainly not all. Its not hard to set up a sourceforge account with a free untraceable address from someone like gmail that you then only access from someone's open wireless network.
"Not the point anyway. The point is to discourage bad behavior, and you can discourage a single person a lot more effectively than a corporation."
So you can more easily discourage an individual who can easily remain anonymous and who might not have any assets and thus be willing to risk it all if they did somehow get caught than you can a large corporation who you can file a class action lawsuit against? I think you are in denial.
"Nope. Consider the ongoing discussion about Microsoft Vista and an apparent network slow down while playing music. The question of what's happening would be settled quickly by a code audit, except that no one outside of Microsoft is able to do that."
<sarcasm>Right, because code audits are always perfect and catch every flaw in existence. Thats why open source software is always bug free.</sarcasm>
Look, I'm not arguing that OSS has no advantages. Of course it does. But it also has its share of disadvantages, even if the Richard Stallman and his zealots refuse to believe it.
"What you say might apply to people who only very ocassionally use a computer for printing something, but those wouldn't be what I call normal users, just like I wouldn't call somebody who gets out their bycicle out once a year a cyclist."
Ok, but if you want to be all elitist and dictate who is a computer user and who is not, why not go all the way and rule out all Windows users? Those who use their computers for only a few functions make up a large number of computer users, probably the majority. In fact, nowadays even I don't use my home computer for much more than browsing the Internet and reading my email, as I spend so much time on my work computer I don't want to do much more when I get home. Granted back in college I used it for a lot more, but college students make up a minority of all computer users.
"No, the company is simply small and doesn't concentrate on development. I double as the sysadmin. That's all the IT staff (me)."
If your company is selling software (otherwise it would irrelevant to the point) and you are the entire IT staff, then your company probably has problems.
"Vulnerabilities? I don't remember MS being ever sued for that, and they've had plenty."
I should have been more clear. Intentional vulnerabilities will result in lawsuits.
"Yes, because people got a pile of money from Sony. Let's see, the settlement was: "Customers who exchange their XCP CD can either download three albums from a list of over 200 titles, or claim a cash payment of $7.50 and a free download of one album"."
Times a lot of customers.
"In comparison, if this was a normal person and not a multinational, you'd have the guy bankrupt for the rest of his life. While I imagine you wouldn't get a whole lot out of it, I imagine you could get more than $7.5, and the result for the offending party would look a lot more like a punishment."
First, you are assuming you can catch him, which is unlikely if he is an anonymous OSS developer. Second, that isn't how bankruptcy works. It is perfectly possible for someone to recover from bankruptcy. Third, it doesn't matter if the other party is a multinational or an individual, class action lawsuits don't return that much to each person in the suit.
In other words, you wouldn't get a penny if this was an individual. So take your $7.50 and consider yourself lucky.
Very few freeware applications are as widely used as the Linux kernel, either. So if thats the scope of the vulnerability you are seeking, neither is really a good way to achieve it. But the smaller attacks that only effect a few systems can still be dangerous. And some of those smaller open source apps can be pretty common. Consider something like gaim/pidgin. It is a relatively small project, and I believe much of it was developed by students. Yet it is used by a lot of people, and it has had security issues in the past.
" There's a difference of scale. In the first case you have a developer who wrote the whole thing, got found out, and inexplicably managed to convince somebody to stay silent. This developer has the size on their side, because the chances of that people won't look very well at a 50K line program is much greater than that something will be missed in a 10 line patch."
Fine, swap my example of a developer giving a patch with one starting their own project if it concerns you so much. My argument will be just as valid. The distinction is a red herring.
"You've not dealt with enough Windows users, I see. Most of them seem to install any crap they can find anywhere. "
No offense, but the Windows users you know are not representative of the community as a whole. Many just use whatever they are given, and don't bother installing anything else unless they absolutely need it. If Windows users were always prone to download any app they could find, why would the EU be concerned about what software MS pre-installs on their OS?
"That's not my point, my point is that while the Debian maintainer might not read all of firefox, the Red Hat one is probably not looking at exactly the same parts source."
And if the vulnerability only makes it in one or two distros? Your argument is contingent on it being widespread. But thats not always the case.
"No, but this is prefectly possible for a distribution to do. End users shouldn't be compiling anyway. The distribution making sure their toolchain is good is enough."
Once again, this assumes the software comes from a distro, which we have already established is not always the case. And even then, I'm sure distro owners don't do this for every package and every patch they include.
"Uh huh. I work at a company (working on internal code though). I could put any crap I wanted there, and probably nobody would ever find out, because nobody else at the company is capable of reading the simplest code."
Ok, your company sucks (either that or you are an arrogant prick who thinks all his coworkers can't do a thing when in reality they are just as capable as yourself). Whats your point? There are plenty of open source projects where the developers miss things as well (as I illustrated in my last post).
"You can't even boycott them because you're not their customer -- they sell their crap to somebody else."
Boycotts are for sissies. If a commercial software program is found with a vulnerability, they will be the subject of a lawsuit. And then they will go back and check the records to see who inserted that code, and you will be caught red handed.
"Besides, there are no real consequences for a company. Sony got off very, very lightly for what they did. Did anybody go to jail? Of course not."
Sony is currently facing class action lawsuits against them for rootkit incident. And they did get a lot of bad press, which certainly hurt their sales. The lack of criminal prosecution (so far) doesn't mean they got off cleanly.
In comparison, a hacker who submitted a patch or started a project anonymously with such a vulnerability could get off without a scratch. And even if he did get caught, its highly unlikely that he would have the assets for you to sue him and recover any damages.
"Ok, if you're so clever, provide an example of code that reads a file without making it easy to tell what it's doing, while avoiding looking suspicious."
First, I never said I was a hacker, so this really isn't my area of expertise. But as to how I would probably go about it if I were...
First, the actual reading of the file would be done by some existing code that processing needed files, so I wouldn't be adding any obvious code that opens files. And it would probably have to log the contents it is processing if an error occurred (so the evil software would then be able to do something with it. Then when I passed in the file it is not supposed to access, I would probably use some sort of generated regular expression that could (on certain inputs) match extra files (including whatever I want it to read). Then since those are not considered valid methods, it would encounter an error and logs the contents it was processing.
But again, this is not my area of expertise. I'm sure someone more experienced in this type of work could do a much better job.
"Don't change subject. The original post was about a developer releasing "evil" code, then turning somebody who finds it to their side. Now you're talking about people submitting patches with somethind hidden in them. Completely different scenarios."
Doesn't matter if it is the submitter of a random patch or the original developer. Either one could be anonymous. Yes, I am aware that is not the case with most large OSS projects, but they are not the ones I am worried about.
"Stupidity exist everywhere of course, can't be eliminated 100%. But while for Linux users perhaps 1% of all software comes from unverified sources, for Windows users it's 99%."
I don't know the statistics here, but I'm guessing most Windows users don't install that much (intentionally, at least) that doesn't come with the computer.
"Not all of it, but there are many distributions, which each look at different parts of the source. To sneak something in you'd need to be really sure that part won't get looked at by anybody, and that's hard. Developers watch mailing lists, talk to people who work on the project and use 'svn diff'."
It doesn't need to go in all distributions, just one or two. And it doesn't need to go in the official stable version for people to install it, many people use bleeding edge versions of distros.
" First you build gcc with icc. This is icc_gcc. Then you build another copy of gcc with gcc. This is gcc_gcc. Now you have two gccs with different code generated by different compilers. So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy. You can easily this with more compilers and multiple versions."
"Easily" is obviously a relative term. Are you really suggesting people do this with all their open source software, all so they can avoid running something like AppArmor?
"Well, I still think it can't be defined that the OSS approach is superior. It's not impossible to sneak something in. But in doing so you must take a very high risk of being found out, and if somebody tracks that back to you, well, chances are you're going to have to look for a new carreer. People with a known record of coding nasty things aren't very liked in the software world."
Yes, there certainly are advantages to OSS, but thats not one. I'm fairly certain your chances of having your vulnerability being caught AND it being traced back to you are much greater when you put it in as an employee of a software company as opposed to an anonymous developer of a OSS project.
The whole question of whether or not its possible to sneak in a vulnerability is moot, as I have personally seen it happen. The application (I won't name it, as they did fix the problem) would allow (under default settings, with a certain add on installed) an attacker to execute
"But you're admitting that it is not guaranteed? "rare" != "never"."
Of course. I never said commercial software is guaranteed to be perfect. That obviously isn't the case.
"You have only your faith in the company who wrote the code that it was properly reviewed and audited prior to release."
Just as you have only your faith in the open source community that it was properly reviewed and audited prior to release. Remember, I'm not arguing that commercial software is inherently better than open source, only that it is not inherently worse. Both have their shares of advantages and disadvantages.
"The difference with open source is that while you may take it on faith that the code has been reviewed, you have the opportunity to do it yourself..."
Only if you have both the ability and time to do so. Most people don't.
"...or pay someone to do it for you. "
Thats exactly what you are doing when you purchase commercial software. Yes, sometimes the people you are paying do a crappy job, but that can happen with the people you hire to work on the open source as well.
"This sort of "evil" is very transparent. You can code a hidden buffer overflow/exploit/backdoor in such a way that it's not obvious (= instead of == for example, caught in the Linux kernel once). But how do you hide an access to say, /proc/interrupts? You need to spell out the filename, and there's got to be an open or fopen for it somewhere. Any attempt to encode the filename is going to be weird and suspicious. Plus, file parsing would be quite a bit than a single line of code, so it's hard not to notice something is being read, stored, etc."
Would it be difficult? Sure. But if you think it is impossible to hide an access to a file you are not supposed to see, you are obviously either new to writing software, or you lack imagination.
"Uh huh. Such a thing would be an outright admission of evildoing. Depending on what is being done it might be enough for a lawsuit, and definitely enough for mass publication all over the web to ruin the developer's name."
Thats an example of why such activities should be rare in the commercial world, where the developer's name, address, social security number, etc., are all on record. But not in the world of many open source projects where it is perfectly possible for someone to be practically anonymous when they submit their patches.
"But 99% of Linux software is delivered by the distribution, with the package maintainer often being completely unrelated to the developer."
Considering how many software packages a person typically has installed on their machine, that extra 1% is pretty dangerous. Yes, the official packages you got straight from the distro may all be fine, what about that new upgrade you went to that great new rpm repository your buddy told you about?
"You can bet that eg, the Debian maintainer of Firefox looked at the source."
You honestly think the owners of the distros look at all the source of each package they include? You must think they have no lives whatsoever.
"That's a tricky one, but you can use a different compiler."
I fail to see how that helps. How do you know the different compiler isn't the one with the Trojan? Its like if we were picking apples from a tree and I point out you have no way of knowing the one you just picked hasn't been poisoned, you throw that apple away and pick another one.
"It's easy to make a compiler that hiddenly changes some well known part of the source, but it's much harder to deal with a complete reorganization of it. To keep it up would need updates to the evil compiler."
It only needs to get in there once. And besides, I really don't think it would be that difficult to insert something generic like a keystroke monitor that would effect pretty much anything compiled with it.
"If Skype was open source we wouldn't be having this discussion at all."
I don't doubt that at all. A problem with an open source program rarely is treated the same as a problem with a commercial app by /. But that says more about the /. culture than it does the differences between open source and closed source.
I'm not saying don't use open source software. Just don't pretend it is immune to the problems that plague commercial software and forget about all precautions (like not running something like AppArmor, to tie this back to the original point) just because what you are running is under the GPL.
First of all, it is rare that only one person reads the source for any commercial software product. Code reviews are standard in most organizations, and even if not, there are many developers at work maintaining that code.
Second, with open source apps, you really don't know that. It is perfectly possible for someone to submit a bad patch and no one bothers to really look at it in depth (at least not as in depth as you would need to catch a well disguised security breach). A lot of people use software assuming someone else has audited it and made sure there is nothing wrong with it solely because it is under the GPL. But that is a very bad assumption to make.