Red Hat Building Up New Contrib Area

A reader writes " Looking for an xmms-kde RPM, I've stumbled across rhcontrib.bero.org - looks like Red Hat is building up a new contribution area. Looks quite interesting, but sloow."

Building Trust for RPM Packagers

[winterstorm]

Redhat's new contrib area will hopefully be an excellent central repository and storage area for third party RPM packages. RPMfind.net is cool too. I think something else is needed at this point though. We need some way to build trust between RPM Packagers and RPM users.

RPM already allows one to embed a PGP signature, but this doesn't allow one to trust the RPM, it only gives you a new tool to assist in verifying some information about the RPM. It would be nice if there was an external mechanism to track other verifiable information about RPMs and RPM packagers.

I'm willing to setup a mailling list at trustedrpm.net [trustedrpm.net] if any RPM packagers are interested in dicussing how a system of trust could be developed

.

Lots of Repositories

[winterstorm]

I like the idea of there being many repositories for third-party or special packages. There are lots of these for both .deb and .rpm packages. For RPM there is even the rpmfind.net [rpmfind.net] system for searching repositories of RPM by various criteria.

What is lacking is some way to identify which packages can be trusted and which can't. For instance if you go to the rpmfind.net homepage you'll find out they their DNS was hacked and that any RPM's downloaded recently should be suspect. There is no way to verify RPM or DEB packages other than a PGP signature. Most thired party packages don't include a PGP signature, and even when they do there is no way to verify it, and even when there is little way to use that as a basis for establish trust. Even if you know the package was signed by "Joe Smith" and "Jim White" has also signed Joe's signature, you don't know why you should trust either of them.

Both DEB and RPM could benefit from a system for identifying what a package should and shouldn't do if it is to be "trusted" and what information about the package and packager should be verifiable, and how it can be verified.

compare to debian

[gmhowell]

There was an Ask Slashdot yesterday wherein someone asked how apt-get compares to urpmi. One thing missing in the discussion was the serious number of debian sites and repositories. Why don't these exist for RH? Something like this would make the RPM based packages much better.

Or perhaps they always were. I finally switched to Progeny the other day, being totally fed up with RPMs.

Re:Lots of Repositories

[RGRistroph]

The way PGP signing is supposed to work is that if the package was signed by "Joe Smith" and "Jim White" has also signed Jor's signature, you are supposed to check the people who signed Joe's signature, and the people who signed them, etc, until you find someone whose signature YOU signed.

If you never sign someone's signature, that's like saying you never trust anyone -- so it shouldn't be surprising that you don't trust the rpm producers.

If you sign stupid people's signatures, then you may trust their signature, but not the signatures they sign.

That's probably as close as you can get to a system for verifying rpms (or any other kind of data), aside from some usability enhancements and integration into various tools. After all, if you have a chain of signed signatures to the rpm signer, then it doesn't matter that rpmfind.net was hacked, does it ? Root access on rpmfind.net doesn't mean they can forge the signatures (unless they broke the public key encryption).

That's why it's important to use GPG, and sign the signatures of people who you can meet in person, especially if you are a developer. The PGP/GPG signatures on the rpms won't mean much if you are not a user yourself.