Re: centralized metadata for security

On Fri, 7 Nov 2008, Muayyad AlSadi wrote:

>> If yum instead did what you suggest, it may well be unable to find
>> packages that the Current metadata suggest, because it is trying the
>> stale mirror it downloaded the old metadata indicator from.
>
> that won't happen, because I did not say let's take a radon mirror,
> I said let's take the central secured mirror that all other mirrors
> are rsync from.
>
>>> Or perhaps my logic is absurd..
>>
>> Your logic is not absurd. If yum downloaded all the metadata from one
>> point then that point would be come a bottleneck, badly.
>
> I did not say all the meta data but just repomd.xml it's a very small
> file (2.7K) that have filenames and their checksums, take a look at
> the output of
>
> wget -O - http://download1.rpmfusion.org/free/fedora/development/i386/os/repodata/repomd.xml
> 2>/dev/null
>
> or
> wget -O - http://download.fedoraproject.org/pub/fedora/linux/releases/9/Everything/i386/os/repodata/repomd.xml
> 2>/dev/null
>
> it looks like this
>
> <?xml version="1.0" encoding="UTF-8"?>
> <repomd xmlns="http://linux.duke.edu/metadata/repo">
>  <data type="other_db">
>    <location href="repodata/other.sqlite.bz2"/>
>    <checksum type="sha">21e97d609abaf58c50661cb97d5c8aa2f07a962a</checksum>
>    <timestamp>1210184312</timestamp>
>    <open-checksum
> type="sha">62b710c5ae9677f7f95941e819c126406a138253</open-checksum>
>    <database_version>10</database_version>
>  </data>
>
> and this is for security reasons
> this way you will be sure that all the meta data are right because
> they match the checksum from on repomd.xml found on the trusted server

Better yet, provide a cryptographic signature of the repomd.xml - which 
yum now supports.

Or, alternatively, provide all the mirror info in a file like repomd.xml - 
but in the metalinks format, which yum also now supports.

:)

-sv