I read that Linux kernel has 29 million lines of code. How does one know for sure that there are no unnecessary code lines in some files that allows backdoor access or something else.
In: 0
Access to the main code repository is still restricted to a short list of people. In the case of the Linux kernel, there is one master copy held by Mr Linus himself. Due to the size of the project, most of the work is broken down into subsystems with their own person in charge. Anybody can submit a patch to the subsystem maintainer for what they want to update, they accept it into their code repository and will give it to Linus to accept into the next release.
In smaller projects, it may simply come down to a much smaller number of people.
There is almost certainly a review system for updates submitted. Github has web based review. The linux kernel runs on an email based mailing list. People who are interested in projects do review the submissions. Often robots are doing testing of updates submitted. Malice is usually caught before it gets accepted. Overly large and complex updates are most commonly asked to be broken into a smaller number of bite-sized updates to make the review process easier.
Oh people have absolutely *tried*, and in a few cases succeeded for a short while. But these projects run themselves like their own organizations with rules and policies.
Its not like there are people analyzing the entire Linux kernel alone…. Although maybe there are. But there are thousands of people looking at separate parts of it. So there’s a decent likelihood that each file and/or code line has had multiple sets of eyes on it.
It really boils down to trust. You have to place trust in the commercial closed-source products too. How likely is it that each developer’s code is being analyzed line by line to ensure they didn’t drop in a back door? Or checked for overlooked vulnerabilities? Security checks take time and money. Companies want their product on the market generating revenue, not sitting in development being scrutinized for obscure potential abuses.
At the end of the day a popular open source project is likely to have had more eyes on each piece than a privately developed closed-source project. Its not perfect, but neither is private development.
When you modify the code you are required to publish your modifications. However that does not mean that the Linux project need to include your modifications into the official source code. Your modifications will be reviewed, for Linux this will be done by at least three or four different reviewers but most other projects require only one or two reviewers before they accept a patch. But all of this happens publicly so anyone can review your code before or after it have been accepted. Typically other developers working with the same code will take a look at it. Even after the patch have been accepted into the official code base there are people looking through the code for exploits and bugs. The major Linux distributions, such as Red Hat, Canonical (Ubuntu), Suse, etc. have hired people to look through the code of the Linux kernel and other important open source projects looking for issues. And other developers working in the same area of the code base will also look at the code you wrote. Even a lot of advanced users will end up looking into the code they are working opposite trying to figure out how it works and why it does what it does.
This means that open source code have lots of people looking at it. Especially popular projects such as the Linux kernel. This is unlike closed source projects where the code is maybe only reviewed one or twice by members of the same development team. So it is much harder to sneak any back doors into an open source project then a closed source project. Of course it is not perfect and there have been some high profile security bugs in open source software as well which have gone unnoticed for a long time. However open source software have fewer bugs per line of code then closed source projects and when security bugs are found they are usually found and fixed before any evidence that they have been exploited.
Access to the main code repository is still restricted to a short list of people. In the case of the Linux kernel, there is one master copy held by Mr Linus himself. Due to the size of the project, most of the work is broken down into subsystems with their own person in charge. Anybody can submit a patch to the subsystem maintainer for what they want to update, they accept it into their code repository and will give it to Linus to accept into the next release.
In smaller projects, it may simply come down to a much smaller number of people.
There is almost certainly a review system for updates submitted. Github has web based review. The linux kernel runs on an email based mailing list. People who are interested in projects do review the submissions. Often robots are doing testing of updates submitted. Malice is usually caught before it gets accepted. Overly large and complex updates are most commonly asked to be broken into a smaller number of bite-sized updates to make the review process easier.
Oh people have absolutely *tried*, and in a few cases succeeded for a short while. But these projects run themselves like their own organizations with rules and policies.
Its not like there are people analyzing the entire Linux kernel alone…. Although maybe there are. But there are thousands of people looking at separate parts of it. So there’s a decent likelihood that each file and/or code line has had multiple sets of eyes on it.
It really boils down to trust. You have to place trust in the commercial closed-source products too. How likely is it that each developer’s code is being analyzed line by line to ensure they didn’t drop in a back door? Or checked for overlooked vulnerabilities? Security checks take time and money. Companies want their product on the market generating revenue, not sitting in development being scrutinized for obscure potential abuses.
At the end of the day a popular open source project is likely to have had more eyes on each piece than a privately developed closed-source project. Its not perfect, but neither is private development.
Access to the main code repository is still restricted to a short list of people. In the case of the Linux kernel, there is one master copy held by Mr Linus himself. Due to the size of the project, most of the work is broken down into subsystems with their own person in charge. Anybody can submit a patch to the subsystem maintainer for what they want to update, they accept it into their code repository and will give it to Linus to accept into the next release.
In smaller projects, it may simply come down to a much smaller number of people.
There is almost certainly a review system for updates submitted. Github has web based review. The linux kernel runs on an email based mailing list. People who are interested in projects do review the submissions. Often robots are doing testing of updates submitted. Malice is usually caught before it gets accepted. Overly large and complex updates are most commonly asked to be broken into a smaller number of bite-sized updates to make the review process easier.
Oh people have absolutely *tried*, and in a few cases succeeded for a short while. But these projects run themselves like their own organizations with rules and policies.
Its not like there are people analyzing the entire Linux kernel alone…. Although maybe there are. But there are thousands of people looking at separate parts of it. So there’s a decent likelihood that each file and/or code line has had multiple sets of eyes on it.
It really boils down to trust. You have to place trust in the commercial closed-source products too. How likely is it that each developer’s code is being analyzed line by line to ensure they didn’t drop in a back door? Or checked for overlooked vulnerabilities? Security checks take time and money. Companies want their product on the market generating revenue, not sitting in development being scrutinized for obscure potential abuses.
At the end of the day a popular open source project is likely to have had more eyes on each piece than a privately developed closed-source project. Its not perfect, but neither is private development.
When you modify the code you are required to publish your modifications. However that does not mean that the Linux project need to include your modifications into the official source code. Your modifications will be reviewed, for Linux this will be done by at least three or four different reviewers but most other projects require only one or two reviewers before they accept a patch. But all of this happens publicly so anyone can review your code before or after it have been accepted. Typically other developers working with the same code will take a look at it. Even after the patch have been accepted into the official code base there are people looking through the code for exploits and bugs. The major Linux distributions, such as Red Hat, Canonical (Ubuntu), Suse, etc. have hired people to look through the code of the Linux kernel and other important open source projects looking for issues. And other developers working in the same area of the code base will also look at the code you wrote. Even a lot of advanced users will end up looking into the code they are working opposite trying to figure out how it works and why it does what it does.
This means that open source code have lots of people looking at it. Especially popular projects such as the Linux kernel. This is unlike closed source projects where the code is maybe only reviewed one or twice by members of the same development team. So it is much harder to sneak any back doors into an open source project then a closed source project. Of course it is not perfect and there have been some high profile security bugs in open source software as well which have gone unnoticed for a long time. However open source software have fewer bugs per line of code then closed source projects and when security bugs are found they are usually found and fixed before any evidence that they have been exploited.
When you modify the code you are required to publish your modifications. However that does not mean that the Linux project need to include your modifications into the official source code. Your modifications will be reviewed, for Linux this will be done by at least three or four different reviewers but most other projects require only one or two reviewers before they accept a patch. But all of this happens publicly so anyone can review your code before or after it have been accepted. Typically other developers working with the same code will take a look at it. Even after the patch have been accepted into the official code base there are people looking through the code for exploits and bugs. The major Linux distributions, such as Red Hat, Canonical (Ubuntu), Suse, etc. have hired people to look through the code of the Linux kernel and other important open source projects looking for issues. And other developers working in the same area of the code base will also look at the code you wrote. Even a lot of advanced users will end up looking into the code they are working opposite trying to figure out how it works and why it does what it does.
This means that open source code have lots of people looking at it. Especially popular projects such as the Linux kernel. This is unlike closed source projects where the code is maybe only reviewed one or twice by members of the same development team. So it is much harder to sneak any back doors into an open source project then a closed source project. Of course it is not perfect and there have been some high profile security bugs in open source software as well which have gone unnoticed for a long time. However open source software have fewer bugs per line of code then closed source projects and when security bugs are found they are usually found and fixed before any evidence that they have been exploited.
Latest Answers