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 configuration). 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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp_ubezrixf2.pgp
Description: PGP signature