I'd say we should just make a format that we expect .src.rpm and
md5sum
announcements in, and ask people to conform to that. I think quick
and
effective QA will be sufficient incentive.
For average size packages, MD5 checksums and GPG signatures are not needed at all. The included tarball and maybe 1-2 patches can and must
be
verified. Signatures get important for large packages, which include
lots
of patches, for instance.
Given all the rhetoric on this list and on the fedora.us website, I see no reason why rpm signatures on packages and md5sums should not be required. They're easy to create. If they're not going to be required, then we need to relax the requirements[1,2,3] for GPG signing everything that goes into bugzilla too. Who determines when a package is "large enough" to require a valid signature?
IMO, this kind of ambiguity is killing the project. It's impossible to streamline a workflow when you allow for every possibility under the sun at every step.
Personally, I feel that package submissions should be GPG-signed, and we should eliminate posting the md5sums for the .src.rpm. Clearsigned md5sums provide some assurance that the author hasn't changed the package since it was QA'd, and provide a valuable addition to the QA review, but not the initial package submission.
[1] http://www.fedora.us/wiki/PackageSubmissionQAPolicy [2] http://www.fedora.us/pipermail/fedora-devel/2003-March/000459.html [3] http://www.fedora.us/wiki/PUBLISHCriteria
--erik
On Wed, 10 Mar 2004 17:09:12 -0500, Erik LaBianca wrote:
For average size packages, MD5 checksums and GPG signatures are not needed at all. The included tarball and maybe 1-2 patches can and must be verified. Signatures get important for large packages, which include lots of patches, for instance.
Given all the rhetoric on this list and on the fedora.us website, I see no reason why rpm signatures on packages and md5sums should not be required. They're easy to create. If they're not going to be required, then we need to relax the requirements[1,2,3] for GPG signing everything that goes into bugzilla too.
That's not the point. Clearsigned GPG reviews/approvals are easy to create, too. Yet GPG is considered one of the hurdles to "doing QA". It is also not my intention to start a tiresome discussion of policies. It is my personal opinion as a reviewer, that--although I check whether a src.rpm is signed--I rely on checking the contents of the src.rpm, because the signature doesn't add any safety for me as a reviewer. Neither does a posted MD5 digest. The single important step is to indentify an approved package with its MD5 or SHA1 fingerprint.
Who determines when a package is "large enough" to require a valid signature?
Common sense.
It's not a question of whether to "require a signature". It's a question of when a signature would make sense.
IMO, this kind of ambiguity is killing the project.
So far the critics say that too many policies turn the project into something that's too complicated. If you require packagers and reviewers to use a specific format for their package requests and reviews, that will be the target of additional criticism.
It's impossible to streamline a workflow when you allow for every possibility under the sun at every step.
Everybody has different requirements.
--