I have concern regarding Fedora's package review process and how its
current policy enforcement seems to make security and code-correctness
take a backseat to functionality and adoption of new packages.
Specifically, I am having issues with the <b>lack of a mandatory code review</b> before a package is added to the official software repositories.<br>
<br>
Recently I was reading review process of an undisclosed forked project,
and the results really made me think twice about trusting the official
Fedora repository. It seems two people who are part of this process
stated that a mandatory code review was not part of the underlying
package review process.<br>
<br>
<blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="tr_bq gmail_quote">
Rahul Sundaram 2012-03-13 09:42:31 EDT</blockquote><blockquote class="tr_bq">
@Christoph Wickert, The quote doesn't mean what you think it does. <u><b>We don't do code review as part of the review process clearly and there is no real history of even checking for functionality</b></u>.
If you want this to change, that is a reasonable position but any claim
otherwise is overreaching. The checklist for instance focuses only on
packaging policy. The worst that could happen is that the package gets
abandoned after a while but that isn't a real problem. It happens
routinely anyway.</blockquote></blockquote>
<br>
<blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="tr_bq gmail_quote">
Christoph Wickert 2012-03-14 08:21:50 EDT </blockquote><blockquote class="tr_bq">
(In reply to comment #35)<br>
> We don't<br>
> do code review as part of the review process clearly and there is no real<br>
> history of even checking for functionality. <br>
<br>
<u><b>I agree that a code review is not mandatory part of a package review</b></u>,
nevertheless I consider it very useful. I recall a review that revealed
serious bugs and even a security issue in one of my packages. Me and
the reviewer worked on patches and I upstreamed them before the package
was released in Fedora. This is how successful collaboration between
developers and package maintainers should look like.<br>
<br>
Besides that, checking for basic functionality *is* definitely part of
the review checklist: "The reviewer should test that the package
functions as described. A package should not segfault instead of
running, for example."</blockquote></blockquote>
<br>
This is a little alarming to me. Honestly, I expect anything that passes
Fedora's package review process to be audited and checked to ensure
there is no underlying malicious intent within software, especially when
it is aiming at being added as part of Fedora's official repositories,
which are generally considered a trusted source for installing new
software.<br>
<br>
I mean, what if I decided to create a fork of XFCE with a few useful
improvements or changes that were not directly accepted by the main
branches policies, and in some obscure regions of the software I plant a
malicious routine. According to the aforementioned quotes; as long as
the package installed correctly, had at least the advertised
functionality and didn't break anything then it would be able to pass a
review, regardless of what surprises I may have hidden inside.<br>
<br>
According to Fedora, their underlying goal of this formal process is:<br>
<br>
<blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="tr_bq gmail_quote">
In order for a new package to be added to Fedora, the package must first undertake a formal review. <b><u>The
purpose of this formal review is to try to ensure that the package
meets the quality control requirements for Fedora. This does not mean
that the package (or the software being packaged) is perfect, but it
should meet baseline minimum requirements for quality.</u></b></blockquote></blockquote>
<br>
I believe the <b>minimum requirements</b> for quality should most certainly include security as a highly important <b>"minimum requirement"</b> for their quality control.<br>
<br>
In this day and age, privacy and security should be the number one
priority of all software. I don't care if the software is a calculator,
desktop environment, service daemon or anything else - anything in the
official Fedora repositories should be able to posses the following
characteristics: <b>Trusted</b>, <b>safe</b>, and <b>stable</b> (within reason). Right now, the current policy enforcement only requires that packages meet the following characteristics: <b>Does not break</b>, <b>at least does what it claims</b>, <b>and seems stable enough for most people.</b><br>
<br>
Personally, I find this to be an unacceptable standard. Especially
coming from a project that is directly associated with a reputable
project like RedHat. Sure, maybe security is more important to me than
most everyone else, but security should at least be important enough to
at least check the code to verify it provides advertised functionality
and nothing more.<br>
<br>
Based on this information, just how "trusted" can Fedora's repositories
be? I mean, it seems like any random person over the Internet willing to
go through a review process can have their software added to the
official repositories, without it being audited for major privacy or
security violations.<br>
I can see an argument being made that "this is only the process for
software which is optional and not directly security-related" and "it is
also only the process for popular and well-known software".<br>
<br>
Well, just because something is optional and not directly
security-related does not mean it shouldn't be able to be trusted in a
secure environment, especially if it is being delivered by Fedora's
official repositories. Also, just because something is popular does not
mean someone won't try to slip something in it before asking for a
"formal review".<br>
<br>
Am I honestly the only person that finds the current policy enforcement to be severely lacking?<br>
<br>
I suppose the only course of action is to create a ticket with FESCo,
and hope they also feel that this method of formal review is lacking.<br>
<br>
I mean, I guess anyone that wanted to verify the integrity of their
software could audit the code themselves, but that seems
counter-productive to having a trusted central repository to begin with.
Sure, the current process requires people to jump through a few hoops,
but it does nothing to safeguard the privacy and security of its
end-users.<br>
<br>
This is just something that should be looked at closer, in my humble opinion.