[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emdebian archive key for Lenny

On Tue, 6 Jan 2009 13:54:13 +0100
Adeodato Simó <dato@net.com.org.es> wrote:

> * Neil Williams [Wed, 31 Dec 2008 14:59:47 +0000]:

OK, time for an update on this. At the Debian-UK BSP, I had a chance to
discuss the issues in detail with Phil Hands with regard to pre-seeding
d-i to handle the key issue (as well as working on RC bugs). I've
just got back from Cambridge and various changes were made in Grip
(including adding the normal d-i udebs to the Grip repositories so that
the udebs can be downloaded from the Grip repository too) to make it
easier to test Grip. After the BSP, Wookey and I successfully deployed
Emdebian Grip (lenny)* on an Acer AspireOne (using d-i, making the final
installation 40-50% smaller than the previous Debian install) and the
balloon3 (arm) board (using debootstrap and some scripting and a
slightly greater reduction in installation size). [0] [1]

* (The full, name for the stable release of Grip will be:
Emdebian Grip 1.0 (based on Debian 5.0 "Lenny")
but for brevity, Grip (Lenny) or Emdebian Grip Lenny are also usable.
There will also be (the much smaller) Emdebian Crush 1.0 (based on
Debian 5.0 "Lenny"). The codename for future releases of both flavours
will continue to match the relevant Debian stable release codename.)

The emdebian-archive-keyring-udeb is now available via emdebian [2] and
the current pre-seeding [3] does allow the udeb to be installed,
providing the key at the earliest stage of d-i (straight after network

The remaining issue is the security gap in downloading the udeb prior
to authenticating the key but this could be resolved in time once the
udeb itself is available within Debian (Squeeze) and the pre-seeding
can be changed to look for the udeb in the Debian archive. (Script yet
to be written but would be apt-based to obtain the benefits of
SecureApt). Closing the security gap *in Lenny* is the remaining issue
and I think Adeodato's idea below is a good solution for that.

This method only works easily with automatic d-i installs - manual d-i
installs that try to select the Emdebian Grip repository without
pre-seeding would fail, so it is a partial answer but not ideal.

> > 3. Only put the Emdebian key into *udeb* (debian-archive-keyring-udeb)
> > in Debian Lenny so that once the D-I images are updated for the final
> > release, only the installer can verify the Emdebian archive - this
> > means that the installed systems have no Emdebian keys installed unless
> > the user subsequently chooses to install the relevant package from
> > Debian. This change has no effect *unless* the installation is
> > pre-seeded to use the Emdebian archive or the user deliberately enters
> > the full Emdebian archive details into the relevant installation
> > prompts
> Of all the options you suggest, #3 is the one that we consider the most
> viable, provided that the d-i RMs agree to it. However:
> > 2. Bring the Emdebian repository/server under the control of
> > debian-release so that the repository can be signed by a key already in
> > debian-archive-keyring, dropping the current Emdebian key completely, or
> > 2a. Bring *a copy of the* Emdebian Grip repository under the control of
> > debian-release so that it can be signed by a key already in
> > debian-archive-keyring, or
> There is a variation of this, which consist in us signing your Release
> file at the time of Lenny release. This has the advantage that, should
> either the Emdebian server or the Emdebian key become compromised,
> installation using d-i is not compromised.

There may be a short delay - depending on exactly when the Lenny
release is made but I'm sure we can cope with that. There is nothing in
the Emdebian Grip stable distribution at this time and it would be
simple to coordinate the migration of the packages and signing of the
Release files on #debian-release.

Would debian-release want to do any checks on the repository itself or
simply verify the signature on the Release file by the Emdebian key?
Wookey can arrange access to the Emdebian server.

Signing the stable Release file with the Emdebian key will be a manual
process, once I'm happy that the migration of packages into stable has
been complete and matches Lenny within the subset of packages supported
by Grip at the time of the release.

What is the process for signing the Debian Release files?
> We'd be okay with doing this, since there is a trust path from the
> Emdebian Release file (explicitly signed by you) to the Debian keyring,
> and it only gets activated on request by the d-i user.

Excellent news, thanks Adeodato. It would close the security gap in the
current method.

> However, how often is the Emdebian Lenny Grip repository to be updated
> throughout Lenny's lifetime? If it's to follow closely Lenny itself, and
> only be updated at point releases, it's not too much hassle to sign an
> extra Release file each time we sign Debian proper's. Is that twhat's
> going to happen?

Emdebian Grip 1.0 (based on Debian 5.0 "Lenny") would be updated in the
same manner as Lenny, once Lenny is released. Therefore, if
debian-release just sign the Release files for Grip stable, that would
not need to be redone any more frequently than for Lenny itself.

The update frequency would be too high to do this for the other
repositories - SecureApt is used for unstable and testing in Emdebian
and across two flavours (Emdebian Grip - binary compatible with Debian
and Emdebian Crush - the cross-built version with functional changes).

It occurs to me that the current Emdebian archive key is different to
the equivalent Debian archive key in terms of expiry and automation.
I've no problems with creating and signing a bespoke archive key for
the stable Release files (with a similar expiry to the equivalent
Debian signing key), if this would be preferable.

> (OTOH I don't know if you plan on rebuilding lenny-security and
> lenny-proposed-updates as well, but that should be less of a concern,
> since those suites could be signed with the Emdebian key -- supposing
> activating -security from d-i happens at a time that emdebian-keyring is
> already installed an active, you should check that if you haven't).

Emdebian Grip is binary compatible with Debian so the current mode is
for Grip to use lenny security (and volatile) directly. This does mean
that certain packages get bigger when a security bug is fixed but that
is probably not a problem. Occasional packages that get *a lot bigger*
can be processed on the Grip device, if users of the stable release want
to do so.

Activating -security does occur after the Emdebian archive key is
obtained via the -udeb - this is a result of the changes advised by
Phil Hands.

[1] http://balloonboard.org/
[2] http://balloonboard.org/lurker/message/20090107.173529.c3639a3e.en.html
[3] http://www.emdebian.org/toolchains/pool/main/e/emdebian-tools/emdebian-archive-keyring-udeb_1.4.14_all.udeb
[4] http://www.emdebian.org/grip/index.html#preseeding


Neil Williams

Attachment: pgpyhoVrqfFun.pgp
Description: PGP signature

Reply to: