Think about the practical implications of this. Take, say, MATE or Cinnamon, both recently added or trying to be added to Fedora repos. This would require both the packager and reviewer to be a) capable of and b) have enough time to review the _entire_ code base of each project and declare that they found no security issues. It's an incredibly difficult process.
While I understand that the practical implications of mandatory code review would be taxing and difficult on the team, it would still be far better to have trusted packages versus new packages, especially when it comes to forks of large projects. If a code review is not possible due to an extremely large project, then why not at least verify the identities of anyone that wants to submit a package to an official repository? That would at least make maintainers accountable if something like that did occur, which would make it less likely to happen. Only appropriate members of the Fedora team would have access to information regarding the identity of a maintainer in question. This would be a giant leap in the right direction without requiring such an extremely taxing overhead.
For example, take MATE and Cinnamon as the example. Verify the maintainer that wishes to publish it within the official repository is indeed part of the development team, verify the team members identity, and then proceed with the normal package review. This would at least ensure that the package is going to be maintained by the developers, the person in charge of getting the package into the repository is identified and thus able to be verified, and that the package follows the existing guidelines. My point is: Just don't let any random person over the Internet be able to submit a package into the official repositories without having some accountability for nefarious actions. While it won't stop all possible instances of such an attack vector, it would at least be a more trusted solution than what we currently have in place.
While I agree if malicious code were embedded within a package it could be extremely difficult to detect, and I understand Fedora simply does not have the resources to perform security audits on large projects, there still needs to be a better way to allow packages into the official repositories. The current policy does not seem to take security into account at all, and takes everything on good faith. While I understand my suggested approach is not practical, but neither is taking everything in good faith.
What would be so wrong with having a dedicated security team? Their job could be to ensure packages added into the repositories are more trusted by verifying the identity of the maintainer, ensuring the maintainer is part of the actual development team of the project in question, and auditing the code when possible and practical to ensure more trust in Fedora's repositories. While it is important not to disallow new developers to add their projects to the repositories, it is just as important to ensure they will have some form of accountability in the event that something like this did occur. The damage may already be done at that point, but it would likely deter most individuals. You could also offload formal reviews onto this team as well. If the resources just are not there for such a team, then I can understand that. However, if the resources were there for something like this to be done, it would be far better than the existing solution.
It wouldn't take a "corpse of elite coders" to simply verify the source, and thus put more trust into the repositories.
I still think mandatory code reviews should be in place where possible, especially for smaller projects. They may not be mandatory for large projects, and that is fine. However, taking all packages on blind faith just seems a little silly to me, especially when it is within the reach of your existing resources to do so with smaller projects.
There just has to be a better way to place trust in the repositories.
Anyway, thank you for taking the time to respond to me, Adam. I hope you do not think I am tying to be argumentative, because I am not. I just wanted to give some feedback, and hopefully get more people thinking about practical solutions that could help improve the package review process as a whole.
For example, take MATE and Cinnamon as the example. Verify the maintainer that wishes to publish it within the official repository is indeed part of the development team, verify the team members identity, and then proceed with the normal package review. This would at least ensure that the package is going to be maintained by the developers, the person in charge of getting the package into the repository is identified and thus able to be verified, and that the package follows the existing guidelines. My point is: Just don't let any random person over the Internet be able to submit a package into the official repositories without having some accountability for nefarious actions. While it won't stop all possible instances of such an attack vector, it would at least be a more trusted solution than what we currently have in place.
I'd take a high level summary and say that Fedora's processes and policies, broadly, assume an element of good faith. Your proposal appears to take the opposite tack: a defensive posture, assuming all new code is bad until proven otherwise. This is a very difficult stance for a project like Fedora to take convincingly. After all, if someone's trying to trojan in something evil, why would you expect them to leave it in plain sight? Surely they'd try to obfuscate it as much as possible. As the Obfuscated C Code Contest and others show, there's all sorts of possibilities down this line. If we're going to take a defensive posture to all proposed Fedora packages, we'd need a corps of elite coders to review every submitted package with a fine-toothed comb.
While I agree if malicious code were embedded within a package it could be extremely difficult to detect, and I understand Fedora simply does not have the resources to perform security audits on large projects, there still needs to be a better way to allow packages into the official repositories. The current policy does not seem to take security into account at all, and takes everything on good faith. While I understand my suggested approach is not practical, but neither is taking everything in good faith.
What would be so wrong with having a dedicated security team? Their job could be to ensure packages added into the repositories are more trusted by verifying the identity of the maintainer, ensuring the maintainer is part of the actual development team of the project in question, and auditing the code when possible and practical to ensure more trust in Fedora's repositories. While it is important not to disallow new developers to add their projects to the repositories, it is just as important to ensure they will have some form of accountability in the event that something like this did occur. The damage may already be done at that point, but it would likely deter most individuals. You could also offload formal reviews onto this team as well. If the resources just are not there for such a team, then I can understand that. However, if the resources were there for something like this to be done, it would be far better than the existing solution.
It wouldn't take a "corpse of elite coders" to simply verify the source, and thus put more trust into the repositories.
This is a big reason why I suspect you guys just don't have the resources to beef up your package review policy, and that is okay. None of my suggestions are to be taken as things you should do, but just my personal opinion regarding the situation. I understand that this is not a perfect world, and sometimes you have to make sacrifices to security to benefit the project and community as a whole. I am only asking that the policies be reviewed, and strengthened where possible with any practical solutions anyone can come up with. That is a big reason why I am still spit-balling ideas instead of just expecting someone else to "figure it out".In practice, we have enough trouble just finding people committed enough to perform the currently required review processes. It seems unrealistic to believe Fedora is capable of performing a comprehensive security audit on all the zillions of lines of code it contains and which are regularly added to it...
I still think mandatory code reviews should be in place where possible, especially for smaller projects. They may not be mandatory for large projects, and that is fine. However, taking all packages on blind faith just seems a little silly to me, especially when it is within the reach of your existing resources to do so with smaller projects.
There just has to be a better way to place trust in the repositories.
I can agree with this sentiment. If the need for security is greater than what is reasonably expected from the vendor, it would then fall to the end-user to increase security for themselves where possible. However, I believe that it is still okay to give feedback to the vendor, which is what I am doing.Bodies with really serious security needs, like the NSA, have always taken 'consumer level' products like Fedora and performed their own security evaluations on them. I don't think that's an unreasonable approach. If you have really serious security requirements, then you may need to shoulder some of the burden of enforcing them yourself.
Anyway, thank you for taking the time to respond to me, Adam. I hope you do not think I am tying to be argumentative, because I am not. I just wanted to give some feedback, and hopefully get more people thinking about practical solutions that could help improve the package review process as a whole.
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
