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