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