5:28 a.m.
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.
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.
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...
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".
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.
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.
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.
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.