Open source software development and software security issues (1)

A discussion about Microsoft Windows and Linux based operating systems is sweeping the internet. The discussion involved many people with vested interests and partiality. The discussion was heated by the confusion of the discussion due to the lack of understanding and misunderstanding caused by logic mistakes. The demand for advertising strategies is expected to give the sponsors more attention, and the use of collated statistical data in the allocation of papers is too obvious authority and objectivity to support the discussion with prejudice and questionable facts. Part of the reason for the seemingly never-ending debate about the lack of certainty is that the assessment of security is too much focused on a spin-off: they only study the surface phenomenon of security performance, without in-depth analysis of the reasons for security features. Part of the reason is that, for most proprietary software vendors, the development of open source software is mysteriously new. Therefore, these non-open-source software manufacturers can not understand the open source world for security issues behind the efforts. Part of the reason is that many people involved in discussions are end users who have only a superficial understanding of software security. Even though it experts sometimes fail to understand the efforts of software security in the software architecture and development process, because IT professionals have a deep understanding of network and system security configuration, they tend to have more practical knowledge of open source software development and software architecture than they do. If you want to fill the gap in the public knowledge base about the impact of software security, you may want to write a few thick pieces of this material. But it is possible to make a rough introduction of a limited number of topics from this broad topic, which is the purpose of this article. Finally, Linux and Windows security discussions have become an example of a race. These include more and more basic examples of the benefits and harms of security that serve the open source and the closed sources development model respectively. It's not just a technical issue, it's a social event, and if you look at the discussion more closely, it's more like an economist and game theorist event. So far, the most misunderstood of the two development approaches in most discussions is open source research and development methods. Now let's look at how open source software development considers software security issues. The controversy over the security of open source software is based entirely on erroneous inference. Many of the widely circulated sound and reasonable objections to open source software is what we call the "private and safe" fallacy. One of the most common sayings is: "When it's as popular as a Microsoft program, you'll see how secure it is", and the other is "any sophisticated security hacker can see the source code, so it's not safe". The "private-safe" fallacy limits the discussion of the relative security of Linux based operating systems and Mozilla Firefox browsers. The reality is that "unsafe or open" does not really provide functional security. It can only provide seemingly safe, in fact, the open source development community relies on security principles just the opposite. This principle can also beKnown as "public Security," it includes two basic principles of software security: transparent security and the security of universal access. The security of transparent open source software development is often challenged by anyone getting the source code. The theory is that people who intend to engage in a security attack can find flaws in the code that can constitute an attack vulnerability by studying the source code, making it easier to attack those vulnerabilities. This theory has a certain basis, but it is not the way people think. In fact, it is an arduous task to analyze source code to find defects, classify them, and create defects further. If, as they say, Open-source software is more vulnerable to attack because of the openness of the source code, it is impossible for anyone outside Microsoft to discover any IE flaws. In fact, for any non-trivial application, even this hard work is easier than finding defects through reverse engineering. These techniques need to test a running application, enter malformed information, or use it deliberately, and then check the scalability of the application and the output to determine how and when the program runs away from the application. Maybe one day we'll be able to enter the source code into another program to determine which part is flawed without having to use the reverse engineering technique to look for bugs, but even that day, using binary executable device code files can be as easy as accomplishing tasks without the source code itself. After all, it is not the kind of information that a programmer needs to name a variable or method, but rather the method of constructing the algorithm used to analyze the target software. After all, the device code itself is functionally consistent with the source code of the input compiler. The only difference is that it has a different reliability for a particular programmer. Statistically, this fact does not support the notion that open source software is inherently more flawed. For example, a report from the Code Analysis Enterprise Coverity shows that they found only 985 bugs in 5.7 million lines of the Linux kernel. To compare, a study conducted by the Carnegie Mellon University's CyLab laboratory shows that a representative commercial closed-source program averages 20-30 bugs per 1000 lines. At this rate, the number of bugs in a 5.7 million-line statement can exceed 114,000, which is 114 times times the number of bugs in the Linux kernel. The important role of software transparency in the development of open source software is often referred to as peer review. All of this process is due to the public state of the source code, and the fact that programmers are not able to have a single control entity, such as the CEO's goal is completely consistent with the facts, the people who develop the source code need to manage each other's actions. So very few, but very intense, and bad-intentioned programmers may set aside the "backdoor" argument in the process to be self-defeating in peer review. Strict and prudent code to comply with quality standards will get open source software project codeLibrary acceptance. In fact, if the program is found to be a Trojan virus in public scrutiny, it will be pointed out. But the source code does not disclose has the property right software also to be possible, sometimes actually has specially joins the rootkit function, only then may be discovered when the accident, for instance 2005 second half year famous Sonyrootkit event. 1 2 Next page >> content navigation 1th page: Transparent Security page 2nd: Universal Security to bring the force (0 Votes) Tempted (0 Votes) nonsense (0 Votes) Professional (0 Votes) The title party (0 Votes) passing (0 Votes) Text: Open source software development and software security issues (1) Return to network security home