Re: detached gpg signature on repomd.xml

Jeff Johnson <[email protected]>
Newsgroups gmane.linux.rpm.metadata
Message-ID <[email protected]>
On Aug 28, 2006, at 9:07 AM, Florian La Roche wrote:

>
> The big nono would be using only the header parts without either  
> checking
> the full file or you need to take the header signature and verify that
> as well.
>

By George, I think he's got it!

>> Please remember to verify the package sha1, using data from signed
>> repomd.xml,
>> before using any other information from the *.rpm package. That is
>> the only logically
>> consistent implementation that I am aware of.
>
> The nice part of using the sha1 checksum is that
> - The data is already included in the current repo data.
> - You could think about solving downloads from several mirrors and
>   inconsistent mirrors by building up a sha1 cache of files and can
>   download data from mirrors until you have all needed bits  
> together ;-)
>   This might make mirror selection and how to trust data from several
>   unsyncronized download mirrors much easier.
>

Careful.

Introducing a "cache" means that the application must insure that the  
object
(in this case a package) that has already had its signature/digest  
verified,
  is exactly the same object as before through other means so that  
the overhead
of re-verifying the signature/digest against the same object can be  
dispensed with.

There are few persistent (as in above) trust models I know of that  
make any logical sense
when information is actively downloaded off the wire. Using https, as  
up2date
does, being perhaps one of the most obvious, the local copy of a  
previously
downloaded information can be trusted because it came through a https
pipe and is locally resident.

Alternatively you can just choose to say
	I trust download.fedora.redhat.com and all its mirrors.
up front,. That is the defacto trust model for yum in FC anyways
if the repomd.xml is not being signed and verified, and what users
need is an explicitly stated trust model for an implementation in
order to make their own trust decisions appropriately.

But surely there are other and stronger trust models for rpm-metadata  
that can be more carefully
implemented and described than the existing implementation in  yum  
and anaconda.

73 de Jeff
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.