On 4 Apr 2006 at 14:29, Joachim Werner wrote:
[...]
> This file will be signed with a SUSE key on all products coming from SUSE.
> The
> public key (GPG public key, ascii armor protected) for this key that can be
> used to verify the signature is in the file "products.key" for convenience.
>
> This key will also be imported from the initrd (the initial bootable Linux
> image that always starts first if you run an installation media), so usually
> YaST will already know about it. This is not the case yet on the current
I see no real advantage having the key in initrd (other than security by
obscurity): Anyone wanting to intoduce his own key can do so either in the root
filesystem (instsys) or initrd.
> betas. The initial key is the one YaST always trusts without asking. The key
> is usually also on the installation media as
See above.
>
> /gpg-pubkey-9c800aca-40d8063e.asc
>
> (This key may change. The one above is the one we currently use.)
>
> The signature for "products" is in the file "products.asc".
>
> When YaST detects an installation source it checks if the file "products" is
> there, and then checks if it is signed with a known key. If it is not signed
> at all or with an unkown key, or if the key is on the media, but not trusted
> (yet), the user will be asked what to do.
>
> We sign the "products" file to make sure that nobody can add products to an
> installation source that don't belong there.
But that user could replace the key and possibly re-sign the packages, or could
modify the signature checkingof yast a bit (or use an older version of gpg) ;-)
>
> b) The file "content"
>
> For every product there is a "content" file. If there is no "products" file
> that tells us where the products are, we look for the file in the
> installation source's root.
>
> The "content" file is signed in the same style as the "products" file, so
> there is a "content.key" (usually, but not necessarily the same as
> "products.key").
>
> Compared to "content" files on older releases we have additional data. There
> are two new keys: META and KEY. Here are two examples:
>
> META SHA1 08579e4b28287d6aedd954098b64c6bb49d17367 packages
>
> KEY SHA1 a108c6aab19fe604fa98ef299cdce6e6ba275f09
> gpg-pubkey-0dfb3188-41ed929b.asc # all in one line
>
> META keys are added for all files in the directory named in the key DESCRDIR,
> e.g.
>
> DESCRDIR suse/setup/descr
>
> on a typical SUSE Linux.
>
> Before YaST uses any file from DESCRDIR it will look up the entry in
> "content". This entry is currently an SHA1 checksum followed by the package
> name. This may change to an SHA256 checksum.
>
> The KEY entries list all the keys that YaST should import from the media.
> Those keys can be used for checking RPM signatures and metadata signatures
> and will be stored in he RPM database, so they can be used with "rpm
> --checksig" for package-level verification.
>
> If I get things right, we will also trust those by default because the list
> of
> KEYs is in a file that was signed by the initial key from the initrd that we
> trust by default.
>
> The next step in the chain is the file "packages" in DESCRDIR.
>
> If you are familiar with its syntax you will see that we added a new tag
> there, too, right after the "Pgk:" tag. Here is an example of the first two
> lines of the entry for the default kernel:
>
> =Pkg: kernel-default 2.6.16 13 i586
> =Cks: SHA1 8c8eb2b605e1d626c22bea8dd0c3b05885432b16
>
> Again we have an SHA1 checksum.
>
> So there is a consistent chain of trust from the initial key (that you need
> to
> verify on your own if you don't trust your installation media) via the
> "product" and "content" files to the individual packages. The chain makes
> sure that all those files belong there and haven't been manipulated.
>
> On the package level we may or may not perform an additional "rpm --checksig".
>
>
> 2) The "repomd" or "YUM" format
>
> Here we use the same basic concept. The initial file is "repomd.xml", which
> is
> again signed with a detached GPG signature in "repomd.xml.asc".
>
> I don't know right now if there is a default place for the public key, but
> usually repomd repositories will be used for udpates and as an add-on source,
> so the keys are known to the the system already.
>
> In repomd.xml and all the files referenced from there, a <checksum> tag again
> makes sure that the installation/update source is consistent. Here is an
> example snippet:
>
> <data type="patches">
> <location href="repodata/patches.xml"/>
> <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum>
> <timestamp>1144088097</timestamp>
> <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum>
> </data>
I think there is a slight difference between "SHA" and "SHA-1" ;-)
>
> repomd uses those checksums by default. The only thing we added is signing
> the
> "repomd.xml" file.
>
> So much for the conceptual background. Feel free to comment on the concept if
> you have any questions/concerns.
>
> Now for the problems with YaST and installation sources you may have faced in
> the last couple of days:
>
> The problem is that the signature checks are already in place, but the GUI
> and
> command line options that let you import non-SUSE keys, override key checking
> and integrity checking are not in place yet.
>
> With the final product you will be able to switch all the checks off, so you
> can still use sources that do not use any signing or checksums. But currently
> there are a few bugs with YaST expecting a signature to be there etc.
Should be an option for software installer / YOU ("only accept digitally signed
software/updates" where the user should be able to review his trusted keys)
>
> We will also provide tools for setting up your own signed and
> checksum-enabled
> installation sources ASAP.
>
> I'll keep you posted and will try to answer your questions. If you want to
> put
> this information onto opensuse.org, I wouldn't object. ;-)
>
> I'll try to update opensuse.org on my own as soon as possible, too.
>
> Cheers
>
> Joachim
Thanks.
Regards,
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
