Metadata signing for rawhide

[Nico Kadel-Garcia]

On Thu, Aug 6, 2015 at 8:46 AM, Dennis Gilmore <dennis at ausil.us> wrote:
> On Thursday, August 06, 2015 08:27:44 AM Neal Gompa wrote:
>> In the rpm-ecosystem mailing list, Michael Schroeder from SUSE brought up
>> that we don't sign the metadata for the rawhide repository
>> <http://lists.rpm.org/pipermail/rpm-ecosystem/Week-of-Mon-20150803/000193.ht
>> ml> and it would be nice if it was signed so that he could be sure that the
>> mirrors didn't "do funny things".
>>
>> Is there a reason we don't sign the rawhide repodata? Forgive me for my
>> ignorance, but do we sign repository metadata at all, and if so, how do we
>> do it I'd like to do that for my own repos too.
>
> we do not sign any repodata because it is a a manual step at the end of long
> running manual processes or at the end of long running fully automated
> processes.  The way that mirrormanager handles metalinks mitigates the need to
> sign the metadata.  you get the md5, sha1, sha256 and sha512 sums and
> timestamps of the repomd.xml from mirrormanager that is verifiable through
> https,  assuming you trust fedora infrastructure.  repomd.xml is the file that
> tells you the checksums and data for the other files in the repodata.  you can
> then use the repomd.xml file to verify that none of the other metadata has
> been tampered with. yum and dnf will ignore any mirrors that return invalid
> data.
>
>
> Dennis

What makes you think a site that is poisoning or abusing the metadata
would not simply run "createrepo" and generate entirely new metadata?
I've certainly done it, to build tuned repositories with certain core
components locked down or replaced from internal repositories and to
avoid undesired upgrades from the upstream primary Fedora mirrors. I
particularly went through this with different variants of MySQL,
samba, ecj, and other Java components whose "Requires" settings were
resolved with the wrong packages for my internal use.