On Sun, 2004-10-31 at 14:55 +0100, Matias Féliciano wrote:
Le dimanche 31 octobre 2004 à 13:35 +0100, Nils Philippsen a écrit :
On Fri, 2004-10-29 at 12:45 -0600, Rodolfo J. Paiz wrote: As outlined above, the process of signing repo metadata and the process of signing individual packages isn't that much different in that it needs someone or -thing to do the signing. I think signing repo metadata is good to augment the signing of packages in that someone certifies a specific set of packages, which is a benefit if you e.g. think of some bad guy trying to inject a (signed) iptables package into a mirror repository that by whatever problem wouldn't work together with the kernel already in there.
A "Conflict" field in the rpm is a better solution.
A "Conflict" field is only a reactive solution, i.e. you need to know about the issue (and those with malicious intent won't tell you about it ;-). Signing repo metadata is a proactive measure that might prevent such scenarios even in the case when we don't know about such a situation.
On the other hand the argument that we should use the presence of a (Red Hat) signature as a measure of quality is rather moot in my eyes as I have had a number of my packages out there with great difference in quality and all of them signed, even with a non-Rawhide key ;-). We have to teach the people who think about the signature being a sign of quality instead of origin about its real meaning, we shouldn't conform to their ill views.
Interesting. There is _nothing_ that describe Test release and Rawhide. Nothing. Red Hat did a brilliant job in describing what Fedora is (section About of fedora.redhat.com). Red Hat may describe Test release and Rawhide. These informations may also be in the fedora-release package.
Here's my 2p:
Rawhide is constantly in flux and its quality is variant -- anything between "quite good" and "eats your hamster" is possible.
A test release is a snapshot of Rawhide where we try to not break too many things before, i.e. we usually have a freeze before a test release where the release managers permit fixes and only controlled new features between the freeze and release of the snapshot.
Nils