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