Summary: Secure APT Key Management
Last week I started a discussion[1] to find out the current status of key management in Secure APT which is a release goal for etch and said to be included in the next release of Debian. I don't find the situation terribly promising, though, but here's a summary, so we may come to a solution some day. 1. http://lists.debian.org/debian-release/2006/07/msg00192.html Does one of the proposals below meet the requirements of ftpmasters? If not, what would be their preferred implementation? Secure APT will cause a lot of trouble if key management is troublesome and bound to fail right after the release of etch, when the next key rollover is due to happen, or one year later. Goswin von Brederlow asked[2] ftpmasters to store the public signing keys next to the signed file to have a standardised place where keys for any apt-getable archive can be found. 2. http://lists.debian.org/debian-release/2006/07/msg00193.html Martin Krafft pointed out[3] that there is too much danger of man in the middle or DNS-poisoning attacks for automatic upgrades over the network of keys to be trusted automatically, unless Debian starts using SSL. 3. http://lists.debian.org/debian-release/2006/07/msg00194.html The way he envisions key management is that every Debian machine trusts the SPI CA. Debian should provide a webpage for downloading and verifying keys, protected by SSL/TLS. The use would require easy-to-use tools to install these keys, and proper error messages from APT that will make it obvious what to do. Florian Weimer stated[4] that the only approach known to work is static keys for stable releases and stable security updates. The keys can be stored off-line or on-line, at the discretion of the respective teams. He pointed out that we have botched all yearly key rollovers, and that there is zero evidence that we'll get the first one that reallly matters right. 4. http://lists.debian.org/debian-release/2006/07/msg00201.html Joey Hess added[5] that the last date at which key management can be added/included in the installer will be the final build of d-i initrds, which is going to happen on Wednesday, October 18th, 2006. However, I believe that this would be way too late in terms of code maturity and proper tests. 5. http://lists.debian.org/debian-release/2006/07/msg00202.html Raphaël Hertzog suggested[2] to use two signatures, one from a yearly key and one from a stable release key. The user can decide on their own to trust either a yearly key only or the release key only, and omit a key rollover. The release key could also be stored offline which will reduce[7] the likelihood of being compromised. 6. http://lists.debian.org/debian-release/2006/07/msg00212.html 7. http://lists.debian.org/debian-release/2006/07/msg00221.html Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to cleanly get rid of exim 3 for etch?
Marc Haber wrote: (2) Update exim3 with the warning message in sarge via s-p-u and a point release. If this is a required step upon the upgrade/removal, then your path is flawed. You cannot expect all users who upgrade from sarge to etch to have the most recent updates installed. There are a lot of machines out there that aren't updated against ftp.debian.org, many aren't even updated against security.debian.org. Regards, Joey -- Let's call it an accidental feature. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Summary: Secure APT Key Management
Joey: Thanks for the Bcc. On Sun, Jul 30, 2006 at 12:56:26PM +0200, Martin Schulze wrote: The way he envisions key management is that every Debian machine trusts the SPI CA. Debian should provide a webpage for downloading and verifying keys, protected by SSL/TLS. The use would require I think a proper SSL key, trusted using the regular methods is important, but I don't think it's reliable enough to be our primary/sole verification method. Florian Weimer stated[4] that the only approach known to work is static keys for stable releases and stable security updates. For stable updates, an off-site key would be possible, and I suspect is solely up to the discretion of the stable release managers. For security updates, it's also possible, but a little bit more hassle; so likewise at the discretion of the security team, I guess. That has the added problem that the security team is a little larger than the stable release team, and sharing a key can be awkward. 5. http://lists.debian.org/debian-release/2006/07/msg00202.html Rapha?l Hertzog suggested[2] to use two signatures, one from a yearly key and one from a stable release key. From the discussion previously, it seemed that the way keys would be updated usually was by: (1) someone has a working system (2) they apt-get update, verified by key N (3) they apt-get dist-upgrade to a new apt, which automatically sets key N+1 as a trusted key (4) apt-get update, verified by key N+1 That means there needs to be an overlap between when the new key is added to the distro (both for propogation to testing and included in a stable point release) and the old key is used for signing packages. So having a release key would be something like: * create a new key now that will work for etch's lifetime (assuming etch+1 releases 18 months after etch in July 2008, and gets security support for a further 12 months, that's from 2006-12-01 - 2009-06-30) * (if necessary releasing a new etch key if etch+1 hasn't been released and etch's key is set to expire during the next point release) * creating a new key for etch+1's lifetime prior to it's release by at least one point release of etch, that will last for as long as etch+1's expected lifetime And having an annual key would be something like: * including the 2006 key in apt in all suites (sarge, etch, unstable) * creating the 2007 key in time to be included in the last sarge point release in 2006, and first etch release in 2006 * creating the 2008 key in time to be included in the last etch point release in 2007, and to propogate through to testing before 2008, etc * repeat... I suspect it would be worthwhile to issue DSAs for apt when the new keys are ready as well. Given the synchronisation with the (stable) release team and the security team all the above implies, I think it's their call which of these happens. That leaves SSL as one of the possible means for introducing yourself to the web of trust (oh, I trust SSL, and it says this initial CD/signature/whatever is correct, therefore I'm happy!), as well as signatures by ftpmasters or release managers, or fingerprints from books or other trusted sites. Which is still very worth doing. The user can decide on their own to trust either a yearly key only or the release key only, and omit a key rollover. Note that the online key (whether annual or synched to a release) must be trusted for users of testing, unstable, experimental, testing-proposed-updates, and potentially also security updates and proposed-updates depending on the extra load the security team and SRM group are prepared to take on. The above mechanism can also be used for updating an off-line key used to sign updates to stable -- when etch rN happens, it will be signed by the off-line etch release key, and will contain an apt that includes the off-line etch+1 release key. Cheers, aj signature.asc Description: Digital signature
Re: Summary: Secure APT Key Management
also sprach Anthony Towns aj@azure.humbug.org.au [2006.07.30.1408 +0100]: On Sun, Jul 30, 2006 at 12:56:26PM +0200, Martin Schulze wrote: The way he envisions key management is that every Debian machine trusts the SPI CA. Debian should provide a webpage for downloading and verifying keys, protected by SSL/TLS. The use would require I think a proper SSL key, trusted using the regular methods is important, but I don't think it's reliable enough to be our primary/sole verification method. It's going to be hard to come up with additional methods, IMHO, so if you have anything in mind, please share and I can stop wrecking my brain over it. I think the most important thing still is that we should *never* install and trust a key automatically. I also vote for per-release keys. The argument that they will be easier to crack is invalid IMHO because we cannot use limited lifetime as security measure anyway. Thus, we anticipate that the key will be cracked and have a proper procedure to follow when that's the case. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system crying is the refuge of plain women but the ruin of pretty ones. -- oscar wilde signature.asc Description: Digital signature (GPG/PGP)
please schedule binNMUs on all archs for libsdl1.2
(CC'ing the maintainers) Dear Release Managers, the last upload of directfb made libsdl uninstallable on all archs, blocking many otherwise unrelated packages. I just did a testbuild of libsdl1.2 in my amd64 chroot. The test showed that this gets the binaries correct dependencies on libdirectfb-0.9-25. Therefore please schedule binNMUs on all archs for libsdl1.2. thanks, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please schedule binNMUs on all archs for libsdl1.2
Btw, this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380315 Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please schedule binNMUs on all archs for libsdl1.2
On Sunday 30 July 2006 16:50, Reinhard Tartler wrote: the last upload of directfb made libsdl uninstallable on all archs, blocking many otherwise unrelated packages. I just did a testbuild of libsdl1.2 in my amd64 chroot. The test showed that this gets the binaries correct dependencies on libdirectfb-0.9-25. Therefore please schedule binNMUs on all archs for libsdl1.2. The same goes for other packages too, for example libcairo. See my mail from yesterday asking the directfb maintainer if anyone was managing the transition. If binNMUs are scheduled, it would be nice if all packages that need one could be done. pgpBrlTPeWGAe.pgp Description: PGP signature
Re: please schedule binNMUs on all archs for libsdl1.2
Reinhard Tartler wrote: Btw, this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380315 There are no bug reports needed if binNMUs fix the problem. I already asked for binNMUs for libsdl1.2 yesterday, btw... Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: please schedule binNMUs on all archs for libsdl1.2
Frans Pop wrote: On Sunday 30 July 2006 16:50, Reinhard Tartler wrote: the last upload of directfb made libsdl uninstallable on all archs, blocking many otherwise unrelated packages. I just did a testbuild of libsdl1.2 in my amd64 chroot. The test showed that this gets the binaries correct dependencies on libdirectfb-0.9-25. Therefore please schedule binNMUs on all archs for libsdl1.2. The same goes for other packages too, for example libcairo. See my mail from yesterday asking the directfb maintainer if anyone was managing the transition. If binNMUs are scheduled, it would be nice if all packages that need one could be done. They are already requested in response on your mail from yesterday :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
3.1r3 lkdi status
Here's the status of the lkdi rebuilds for 3.1r3.
l-k-di-${arch}: accepted into stable (no rebuild necessary)
l-k-di-amd64-2.6: build available in gluck:~dannf/3.1r3-lkdi-rebuilds
amd64 guys: should i upload this somewhere?
l-k-di-m68k-2.6: porter poked for update
l-k-di-[hppa,i386,ia64,powerpc,sparc]-2.6: uploaded
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.1r3 lkdi status
On Sunday 30 July 2006 21:00, dann frazier wrote: Here's the status of the lkdi rebuilds for 3.1r3. Thanks Dann. l-k-di-amd64-2.6: build available in gluck:~dannf/3.1r3-lkdi-rebuilds amd64 guys: should i upload this somewhere? They should preferably end up in: http://amd64.debian.net/debian/dists/proposed-updates/main/debian-installer/binary-amd64/Packages I notice that there already are some packages listed there: - cdebconf 0.74.2 - e2fsprogs 1.37-2sarge1 - os-prober 1.04 These three are already in stable for the other arches! - preseed 1.01.1 This one should AFAIK still be in p-u for other arches, but seems to have disappeared there. This needs to be investigated. Martin, Andreas: any idea what happened to them? l-k-di-m68k-2.6: porter poked for update l-k-di-[hppa,i386,ia64,powerpc,sparc]-2.6: uploaded Suggest we wait for the m68k build to become available and then accept the whole lot together into p-u. pgpMmlMNr2T1X.pgp Description: PGP signature
[D-I] Preparing for update in stable - resumed (was: 3.1r3 lkdi status)
On Sunday 30 July 2006 21:00, dann frazier wrote: Here's the status of the lkdi rebuilds for 3.1r3. Now that we are really getting closer, I propose to upload base-installer to stable (proposed-updates) so it can be autobuilt. The reason it needs to be updated is that otherwise kernel selection for alpha will fail after the update. See [1] for the proposed patch. If no one objects I will upload some time tomorrow. Cheers, FJP [1] http://lists.debian.org/debian-release/2006/05/msg00124.html pgpQbAwANVFwj.pgp Description: PGP signature
Re: how to cleanly get rid of exim 3 for etch?
On Sun, Jul 30, 2006 at 02:08:23PM +0200, Martin Schulze wrote: Marc Haber wrote: (2) Update exim3 with the warning message in sarge via s-p-u and a point release. If this is a required step upon the upgrade/removal, then your path is flawed. No, it is not requied, but an additional courtesy towards people who keep their system up to date. The people that don't are going to stick with the unsupported exim 3 anyway. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: temporary oot-modules for 2.6.16
On Thu, Jul 27, 2006 at 02:39:28PM +0200, Daniel Baumann wrote: is it ok to have temporary packages for oot-modules build against kernel 2.6.16 (temporary as in 'as soon as waldi has his linux-modules-extra ready)? squashfs and unionfs can't go into testing without dropping archs atm, therefore the wish to have them in testing, at least, without these archs. Packages are good and uploaded, currently in new and waiting for RM approval. Do you mean ftp team approval? The RMs have nothing to do with approving packages out of NEW. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Not very happy with new directfb upload
On Sat, Jul 29, 2006 at 04:01:04PM +0200, Frans Pop wrote: I do not want to blame you or anything, but I do need your help to get things sorted out. You uploaded a new upstream version of directfb a few days ago (or rather, it was accepted a few days ago), and I'm afraid that looks likely to completely mess up the Beta 3 release plans for the installer. Reason is that libcairo still depends on -24 and thus d-i builds currently fail as that version is no longer available. Also, this means that the new directfb has to migrate to testing before we can release d-i, which in turn means that all packages that depend on directfb have to be able to migrate. Did you already contact the maintainers of packages that depend on directfb? Who is managing the transition? When do you think everything could be ready to migrate to testing? He did request approval for this transition on debian-release earlier in the month, and there were no objections raised: http://lists.debian.org/debian-release/2006/07/msg00147.html So based on the fact that the transition was expected to be possible using binNMUs only, I gave him my approval off-list (on IRC). The binNMUs have all been scheduled now, but the biggest problem looks like it will be that this version of directfb has FTBFS on powerpc. Guillem, do you know about this? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Not very happy with new directfb upload
On Monday 31 July 2006 03:20, Steve Langasek wrote: He did request approval for this transition on debian-release earlier in the month, and there were no objections raised: http://lists.debian.org/debian-release/2006/07/msg00147.html /me kicks himself for missing the implications of that mail (remembering now that he did see it at the time) Guillem: my apologies for thinking you had done this without checking with anyone. The binNMUs have all been scheduled now, but the biggest problem looks like it will be that this version of directfb has FTBFS on powerpc. Guillem, do you know about this? Yes, just noticed that too. Hope this can be resolved soon as that will block progress on the d-i release. As Joey pointed out, we can probably upload the final build of the installer and release it even if this transition has not yet migrated to testing (as all involved udebs are included in the initrds and never loaded from the mirrors). pgpe3mqvnjB0z.pgp Description: PGP signature
Re: BinNMU to get rid of libtasn1-2 dependencies
On Sat, Jul 22, 2006 at 10:36:24AM +0200, Andreas Metzler wrote: On 2006-07-20 Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Jul 16, 2006 at 11:02:49AM +0200, Andreas Metzler wrote: could you trigger BinNMUs for the following library packages as they are still linking against libtasn1-2? sword (dependency pulled in from libcurl3-gnutls-dev which has switched some time ago) Scheduled. Could you please schedule a +b2 binNMU for amd64 and s390? These two archs had an old +b1 binNMU and where not rebuilt. (I'll try to provide this kind of information when I request a rebuild next time.) Queued now. libgnomesu0 (afaict dependency pulled in via libgnomevfs2-0) Also scheduled, on i386 only. Afaict arm needs the binNMU, too. It needs for 0.9.5-3 to be built on arm; it doesn't need a separate binNMU request. The last failure seems to have been a transient build-dep problem, so I've given it back. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patch and nmu
On Tue, Jul 25, 2006 at 06:14:23PM +0200, Julien Danjou wrote: The only version of libsilc-1.0-2-dev in the archive seems to be 0.9.12-4.2, so the versioned build-dependency makes silky unbuildable. I just uploaded 0.9.12-4.3 which fix #331630. So a binNMU of silky should fix #333907. Since the bug report was about a FTBFS error in silky, I don't think that any binNMU is required to fix the bug. The package also seems to have been picked up automatically by all buildds, so this bug has rightly been closed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
