Hi all! Andreas Jaeger asked me to jump in and say a few words on the metadata signing we have added recently to make remote (and potentially insecure) installation and update sources more secure to use. Marcus Meißner has posted a short answer a few minutes ago. Here is the long version:
> > > First of all, it looks like the non-OSS software repository for opensuse > > > beta9 isn't setup right. > > > ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/ > > It looks more like a bug in YaST, please create a bugreprot against > > YaST with log files attached, > Could this be related to the checking with the content.key? If yes, how is > the content.key calculated? On what is it based? > (Perhaps people killfiled the makeSUSEdvd thread, so I ask here again) > Could we get any info on this security thing, or is is security through > obscurity? No, this is all "public" security using GPG with public/private keys. The only thing we will not publish, for obvious reasons, are the private keys we use. ;-) > PS. The reason I ask is because the OP talks about the difference being > that there is a content.key in Beta9. > houghi That's right. I'll briefly outline the metadata and package signing concept for SUSE Linux 10.1 and beyond: We use detached GPG signatures to sign the most important metadata files in an installation source/repository. There are two flavours of installation sources that I'll cover: 1) "Classic" SUSE-style installation sources This is what we are using on the installation media. There are two entry points: a) The file "media.1/products" This file lists the absolute paths (absolute from the root of the installation source file tree) to the products on a media. This is interesting for multi-product media. But usually there is only one line, e.g. "/ SUSE-Linux-Enterprise-Desktop 10" 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 betas. The initial key is the one YaST always trusts without asking. The key is usually also on the installation media as /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. 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> 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. 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 -- Joachim Werner <[EMAIL PROTECTED]> Project Manager Contracts, Migration, SDK Novell, Linux R&D Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
