Re: APT public key updates?
On Fri, Jan 06, 2006 at 07:35:27AM +, Andrew Suffield wrote: However, we don't have to do this annually; with a 2048-bit key, replacing every five years and generating the new key one year before the old one expires should be safe at present. That's true for the crypto strength issue, however if the key was rotated that infrequently, the systems that perform the operation will have succumbed to a lot of bit-rot between invocations and the people doing it will be out of practise. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns wrote: Not directly afaik. If you say Archive Signing Key (Date = 2006-05-01) apt could parse that from gpgv's output and perform the check itself, or add a The key used to sign these packages expired on 2006-05-01; if you obtained this media after that date, you may have a problem. Continue (y/n): warning. I'm not sure off-hand what gpgv outputs in the case of an expired key; it might be feasible to do the above already. [EMAIL PROTECTED]:/var/lib/apt/listsdate Fri Feb 10 02:55:26 EST 2006 It does show as expired in the key list: pub 1024D/4F368D5D 2005-01-31 [expired: 2006-01-31] uid Debian Archive Automatic Signing Key (2005) [EMAIL PROTECTED] And of course the first line is parsable if we needed to. [EMAIL PROTECTED]:/var/lib/apt/listsgpgv --keyring /etc/apt/trusted.gpg ftp.debian.org_debian_dists_unstable_Release.gpg ftp.debian.org_debian_dists_unstable_Release gpgv: Signature made Mon Jan 9 16:06:49 2006 EST using DSA key ID 4F368D5D gpgv: Good signature from Debian Archive Automatic Signing Key (2005) [EMAIL PROTECTED] gpgv: Signature made Mon Jan 9 16:06:49 2006 EST using DSA key ID 2D230C5F gpgv: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] Nonzero exit; odd, it doesn't seem to notice that the key is expired at all. But apt won't use gpgv like that, I suppose, but instead like this: [EMAIL PROTECTED]:/var/lib/apt/listsgpgv --status-fd 1 --keyring /etc/apt/trusted.gpg ftp.debian.org_debian_dists_unstable_Release.gpg ftp.debian.org_debian_dists_unstable_Release 2/dev/null [GNUPG:] KEYEXPIRED 1138684904 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] SIG_ID ZKhvtcKyBPTP/uIh7HV7YuPjbTQ 2006-01-09 1136840809 [GNUPG:] EXPKEYSIG F1D53D8C4F368D5D Debian Archive Automatic Signing Key (2005) [EMAIL PROTECTED] [GNUPG:] VALIDSIG 4C7A8E5E9454FE3FAE1E78ADF1D53D8C4F368D5D 2006-01-09 1136840809 0 3 0 17 2 00 4C7A8E5E9454FE3FAE1E78ADF1D53D8C4F368D5D [GNUPG:] SIG_ID xXpzy5nnFmZ2vx2kRLfQ31tjC6Q 2006-01-09 1136840809 [GNUPG:] GOODSIG 010908312D230C5F Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] [GNUPG:] VALIDSIG 084750FC01A6D388A643D869010908312D230C5F 2006-01-09 1136840809 0 3 0 17 2 00 084750FC01A6D388A643D869010908312D230C5F d-i net-retreiver and debootstrap will currently accept the 2005 key signature above as good even though it's an EXPKEYSIG, since gpgv still says it's a VALIDSIG. I haven't checked apt. But that was a Release file signed before the key expired. What happens if it's signed using an expired key? Let's see: (Note that I created a key, distributed it to root, then moved forward till it expired and tried to sign with it, but gpg wouldn't let me so I edited my personal version of the key to not be expired..) [EMAIL PROTECTED]:~date Sat Feb 20 03:06:53 EST 2010 [EMAIL PROTECTED]:~gpg -u test expire key --sign passwd You need a passphrase to unlock the secret key for user: test expire key 1024-bit DSA key, ID 53FE1BE8, created 2006-02-20 [EMAIL PROTECTED]:/home/joeygpg --list-keys 53FE1BE8 pub 1024D/53FE1BE8 2006-02-20 [expired: 2007-02-20] uid test expire key [EMAIL PROTECTED]:/home/joeygpgv --status-fd 1 --keyring /root/.gnupg/pubring.gpg passwd.gpg gpgv: Signature made Sat Feb 20 03:02:46 2010 EST using DSA key ID 53FE1BE8 [GNUPG:] KEYEXPIRED 1171959238 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] SIG_ID 6FJsP/WgGaXPws8dsBchG+nohOw 2010-02-20 1266652966 [GNUPG:] EXPKEYSIG 81DD5AF853FE1BE8 test expire key gpgv: Good signature from test expire key [GNUPG:] VALIDSIG 9F2124E6216B3E74302F173C81DD5AF853FE1BE8 2010-02-20 1266652966 0 3 0 17 2 00 9F2124E6216B3E74302F173C81DD5AF853FE1BE8 Huh, exactly the same. If my experiements are right, then we can just: 1. Make apt accept EXPKEYSIG VALIDSIG as indicating a valid signature, if it doesn't already. 2. Sign and rotate archive signing keys as we do now. 3. Create a dedicated key for the stable release and sign the stable release with it. This key can be set to expire too, though it could have very different management procedures than the normal signing keys, so expiry might not be an issue. 4. If we need to update the stable release past the key expiry, locally de-expire it and sign the release with it; apt will accept the result. -- see shy jo signature.asc Description: Digital signature
Re: APT public key updates?
Way to go Joey - well demonstrated :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Saturday 20 February 2010 09:15, Joey Hess wrote:
Nonzero exit; odd, it doesn't seem to notice that the key is expired at
all. But apt won't use gpgv like that, I suppose, but instead like
this:
Note though that other packages, like debmirror, do:
my $GPG=gpg --no-tty -q;
[...]
if (!-f $tempdir/dists/$dist/Release.gpg || \
!-f $tempdir/dists/$dist/Release || \
system($GPG --verify $tempdir/dists/$dist/Release.gpg
$tempdir/dists/$dist/Release)) {
pgpZ9nb0orHXk.pgp
Description: PGP signature
Re: APT public key updates?
Frans Pop wrote:
On Saturday 20 February 2010 09:15, Joey Hess wrote:
Nonzero exit; odd, it doesn't seem to notice that the key is expired at
all. But apt won't use gpgv like that, I suppose, but instead like
this:
Note though that other packages, like debmirror, do:
my $GPG=gpg --no-tty -q;
[...]
if (!-f $tempdir/dists/$dist/Release.gpg || \
!-f $tempdir/dists/$dist/Release || \
system($GPG --verify $tempdir/dists/$dist/Release.gpg
$tempdir/dists/$dist/Release)) {
Well, anyone using the mirror can then verify.
If you're just trying to determine whether or not Release corresponds to
Release.gpg this behaviour is much saner than assuming Release invalid,
because debmirror would attempt to fix that by regetting.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: In that case I suggest you rotate it every month for a few cycles. That might not be such a bad idea; having unstable on a weekly rotation cycle that continues until we've worked out how to handle updates, with a final rotation back to the current 2006 key then. BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? Will stable even be installable anymore? How will the updated key be pushed out to stable quickly enough? Will we have to rebuild CDs and obsolete all the old ones then too? Is the current scheme of having overlapping signatures for 1 month long enough, given that stable users might well only update their machines quarterly or so? Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
On Sat, Jan 07, 2006 at 02:32:20AM -0800, Steve Langasek wrote: This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. OTOH, past policies have also required manually tweaking various things in order to do the upgrade (first, upgrade libc5 and install libc6, then install dpkg, then use dselect). Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
Paul TBBle Hampson wrote: On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote: Paul TBBle Hampson [EMAIL PROTECTED] wrote: Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? Well, I meant a different one for each stable, which I guess logically becomes yes... Although as Steve Langasek has pointed out, the Sarge-Etch upgrade will be hard unless the etch key becomes available to Sarge users who've not touched their system since Sarge r0a... I guess this comes down to making the etch key available in some kind of Sarge-signed repository, that you have to add as part of the Etch upgrade, and after which apt-key update will bring you up to Etch key currentness. Assuming apt-key is supposed to be updating from a file in debian-keyring, maybe a new dist (oldstable-upgrade) which really only contains debian-keyring from (new)stable, but which is signed with the oldstable key. Then the online upgrade procedure becomes: Add oldstable-upgrade to your apt-sources apt-get update apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! (Or maybe using aptitude, if that's the recommended upgrade method for Etch as well...) I dunno exactly how apt-cdrom works, but maybe it could automatically pick up that an etch CD has both oldstable-upgrade and stable dists, and therefore the process for CD upgrades becomes: apt-cdrom apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! You'll still get complaints during apt-get update the first time, but the apt-get install at least won't try to reject debian-keyring for being unsigned, because _it_ is signed with a known signature. For the intervening time, security updates and rX releases thereof allow for stable key rollover as needed, either yearly or when compromised. This way oldstable-upgrade gets rolled-away with the rest of oldstable, and isn't part of oldstable per se and so doesn't complicate security updates or whatnot, and is easy to include on the first CD of the new release for upgraders. And the (new) stable key is therefore (transitively) signed with the oldstable key, maintaining the chain of trust, without actually having to muck about with gpg signatures. Consider the following keys: * sarge key (expires after the date we expect to release etch +1) * etch key (expires after the date we expect to release etch +2) * etch+1 key (likewise for etch +3) * 2005 testing/unstable key (expires at the end of 2006) * 2006 testing/unstable key (expires at the end of 2007) * 2007 testing/unstable key (expires at the end of 2008) The following distributions should be signed as follows on the following dates: etch in 2006: sarge key, etch key, 2005 key, 2006 key etch in 2007: sarge key, etch key, 2006 key, 2007 key testing/unstable in 2006: 2005 key, 2006 key testing/unstable in 2007: 2006 key, 2007 key -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns wrote: That might not be such a bad idea; having unstable on a weekly rotation cycle that continues until we've worked out how to handle updates, with a final rotation back to the current 2006 key then. xactly Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Is possible to implement that using gpg? -- see shy jo signature.asc Description: Digital signature
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: On Sat, Jan 07, 2006 at 02:32:20AM -0800, Steve Langasek wrote: This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. OTOH, past policies have also required manually tweaking various things in order to do the upgrade (first, upgrade libc5 and install libc6, then install dpkg, then use dselect). This is true, but with suitable use of package scripts and pseudo-packages to manage the upgrade, apt should now be capable of making this happen automagically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Sat, Jan 07, 2006 at 04:34:48PM +, Colin Watson wrote: On Thu, Jan 05, 2006 at 04:32:29PM -0800, Matt Zimmerman wrote: On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian archive keyring, so no update is needed when Debian keys change. That doesn't mean we (Ubuntu) have solved the problem of how to rotate *our* keys in the event of a key compromise. (To my knowledge, we haven't.) Petter's question was about the key which recently expired, not about a hypothetical compromise. That said, we do have a simplistic mechanism for handling key revocations (as does Debian; it's in mainline apt). It is far from ideal, as there isn't a means for establishing an independent trust path to the new key (it'll be authenticated indirectly by the old key), but it has that flaw in common with the old approach of downloading the key from a Debian web server. Most users probably don't have a trust path to the keys used to sign the archive keys. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Mon, Jan 09, 2006 at 11:43:25AM -0500, Joey Hess wrote: Perhaps expiry isn't exactly what we want -- it's possible we want an archive key that will only verify Release files with a date earlier than a given date; but will continue to do so for an extended period of time. Is possible to implement that using gpg? Not directly afaik. If you say Archive Signing Key (Date = 2006-05-01) apt could parse that from gpgv's output and perform the check itself, or add a The key used to sign these packages expired on 2006-05-01; if you obtained this media after that date, you may have a problem. Continue (y/n): warning. I'm not sure off-hand what gpgv outputs in the case of an expired key; it might be feasible to do the above already. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, Jan 06, 2006 at 04:04:56AM -0800, Steve Langasek wrote: far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. Do we make a habit of asking ftpmasters to bring the archive keys along to keysignings? How many ftpmasters would we want to stand up and tell us that they key in question really is the one that is used to sign the archives before we should agree to sign it?... Just thinking that the keysigning at LCA in two weeks might be a good opportunity to get lots of developers to sign it... Shameless Plug: There's still time to register - see http://lca2006.linux.org.au :-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Mon, Jan 09, 2006 at 04:03:41PM +1300, Nick Phillips wrote: On Fri, Jan 06, 2006 at 04:04:56AM -0800, Steve Langasek wrote: far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. Do we make a habit of asking ftpmasters to bring the archive keys along to keysignings? How many ftpmasters would we want to stand up and tell us that they key in question really is the one that is used to sign the archives before we should agree to sign it?... From a web-of-trust standpoint, this means that, rather than giving others the opportunity to decide for themselves whether they trust the ftpmaster in question, you're making this decision on their behalf. So the true paranoid answer here is all of them, as that's the only defense against one or more of the ftpmasters trying to fake their own key in a way that the other ftpmasters don't notice right away. :) OTOH, if you're happy to ignore this argument, then one ftpmaster standing up should be plenty; and shorter transitive trust paths are definitely to the community's advantage here. (That's basically why I sign the archive keys myself instead of just letting everyone trust the ftpmasters' signatures, after all -- there are people who are a short hop away from my key in the web of trust that may have farther to go to reach an ftpmaster, and vice versa.) This does seem largely equivalent to logging into merkel and checking the file there, anyway; you're trading merkel is compromised and no one knows it for an ftpmaster is compromised and no one knows it as the weakness of the check. For bonus security, it'd be nice if any DD who checked the fingerprint from an ftpmaster in person would also grab the key from merkel. -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: Anthony Towns wrote: Oh, the explanation for current practice is that if the key doesn't change in practice, apps that look at the keys won't cope well with the key changing, and when that becomes important, such as in the event of a compromise, we'll have major difficulties in coping. In that case I suggest you rotate it every month for a few cycles. BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? Will stable even be installable anymore? How will the updated key be pushed out to stable quickly enough? Will we have to rebuild CDs and obsolete all the old ones then too? Is the current scheme of having overlapping signatures for 1 month long enough, given that stable users might well only update their machines quarterly or so? We're already doing security rX updates to Sarge anyway, surely we just need to synchronise the key rollover with those releases? And maybe an rX release if the current archive key becomes compromised? And yes, this means old rX release CD images are obsoleted. _ Maybe the one-true-stable-key idea is the way to go after all... Or maybe an option to apt-key that auto-traces from the key on the CD to the current key, in a sort of certificate chain thingy... But that just reeks of places to break the chain of trust. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpIXxXSFa03Y.pgp Description: PGP signature
Re: APT public key updates?
On Sat, Jan 07, 2006 at 09:14:50PM +1100, Paul TBBle Hampson wrote: We're already doing security rX updates to Sarge anyway, surely we just need to synchronise the key rollover with those releases? And maybe an rX release if the current archive key becomes compromised? This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. This is necessary if we're to accomodate the many Debian deployments which don't have a reliable network connection and are only updated when a new stable release is published. Please keep this use case in mind while designing solutions for the apt key update problem. Cheers, -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
also sprach Steve Langasek [EMAIL PROTECTED] [2006.01.07.1132 +0100]: This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. This is necessary if we're to accomodate the many Debian deployments which don't have a reliable network connection and are only updated when a new stable release is published. Please keep this use case in mind while designing solutions for the apt key update problem. As JoeyH suggests on http://wiki.debian.org/SecureApt, a debian-archive-key package, which contains all keys up until the current one, would do. Then, whenever a new key comes along, a new package is distributed via security.d.o. If we do this, I strongly suggest to move to one-key-per-release cycles. There is no reason to have a new key each January. As a matter of fact, if etch comes out in Decembre 2006, the archive keys it distributes will be usable only for a little more than a month. -- 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 Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! never try to explain computers to a layman. it's easier to explain sex to a virgin. -- robert heinlein (note, however, that virgins tend to know a lot about computers.) signature.asc Description: Digital signature (GPG/PGP)
Re: APT public key updates?
Paul TBBle Hampson [EMAIL PROTECTED] wrote: Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Bernd Eckenfels: Paul TBBle Hampson [EMAIL PROTECTED] wrote: Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? If this means one key per suite (sarge, etch, ...), and no yearly key rollover, I agree. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:32:29PM -0800, Matt Zimmerman wrote: On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian archive keyring, so no update is needed when Debian keys change. That doesn't mean we (Ubuntu) have solved the problem of how to rotate *our* keys in the event of a key compromise. (To my knowledge, we haven't.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Florian Weimer ([EMAIL PROTECTED]) [060106 11:56]: * Bernd Eckenfels: IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Yes, but it breaks a long term usage like web of trust. The Debian archive key does not take part in the web of trust. Anybody who has passed the OpenPGP NM checks should not sign that key. I disagree. There are people who have first-hand knowledge that this key is used for the usage written in the key id, i.e. sign the debian archive. These people can IMHO sign the key. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Steve Langasek ([EMAIL PROTECTED]) [060106 13:05]: The exposure of the archive key is higher, because it sits on an Internet-connected, ssh-accessible server. Also, you don't have to trust AJ's key; in contrast with Florian's assessment of the NM-suitability of the three ftpmasters, one ftp assistant, and one RM who have signed this key so far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. I disagree with that - having this key sitting on merkel means nothing. Checking the configuration on /org/ftp.d.o/katie/katie.conf and the keyring ziyi uses on ftp-master (i.e. spohr) means something. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote: Paul TBBle Hampson [EMAIL PROTECTED] wrote: Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? Well, I meant a different one for each stable, which I guess logically becomes yes... Although as Steve Langasek has pointed out, the Sarge-Etch upgrade will be hard unless the etch key becomes available to Sarge users who've not touched their system since Sarge r0a... I guess this comes down to making the etch key available in some kind of Sarge-signed repository, that you have to add as part of the Etch upgrade, and after which apt-key update will bring you up to Etch key currentness. Assuming apt-key is supposed to be updating from a file in debian-keyring, maybe a new dist (oldstable-upgrade) which really only contains debian-keyring from (new)stable, but which is signed with the oldstable key. Then the online upgrade procedure becomes: Add oldstable-upgrade to your apt-sources apt-get update apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! (Or maybe using aptitude, if that's the recommended upgrade method for Etch as well...) I dunno exactly how apt-cdrom works, but maybe it could automatically pick up that an etch CD has both oldstable-upgrade and stable dists, and therefore the process for CD upgrades becomes: apt-cdrom apt-get install -t oldstable-upgrade debian-keyring apt-key update apt-get update == To recheck signatures... I dunno if this is needed? apt-get dist-upgrade ... time passes echo Welcome to etch! You'll still get complaints during apt-get update the first time, but the apt-get install at least won't try to reject debian-keyring for being unsigned, because _it_ is signed with a known signature. For the intervening time, security updates and rX releases thereof allow for stable key rollover as needed, either yearly or when compromised. This way oldstable-upgrade gets rolled-away with the rest of oldstable, and isn't part of oldstable per se and so doesn't complicate security updates or whatnot, and is easy to include on the first CD of the new release for upgraders. And the (new) stable key is therefore (transitively) signed with the oldstable key, maintaining the chain of trust, without actually having to muck about with gpg signatures. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpmtyYZ9NeHj.pgp Description: PGP signature
Re: APT public key updates?
[Paul TBBle Hampson] Although as Steve Langasek has pointed out, the Sarge-Etch upgrade will be hard unless the etch key becomes available to Sarge users who've not touched their system since Sarge r0a... I guess this comes down to making the etch key available in some kind of Sarge-signed repository Do sarge systems verify the archive key anyway? I thought apt 0.5.28 didn't. But for etch moving forward, I like the ideas I've heard so far about release keys: 1) One key per stable release. The key is generated a month or so before the release, however long is needed to ensure that it be shipped in d-i. This key is then used for the entire length that that release is supported (thus the archive is signed by the keys from both stable and oldstable) - in practice I guess the overlap goes a year or so. 2) The per-release key obviously can't expire exactly when it should, since the release cycle isn't completely predictable, to put it mildly. It might be set to live 4 years or so, and can be revoked later as superceded. 3) Separate keys for other archives - all of the above applies to security, volatile, and amd64 as well. (Unless amd64 makes it to ftp.debian.org before etch.) signature.asc Description: Digital signature
Re: APT public key updates?
Paul TBBle Hampson [EMAIL PROTECTED] wrote: Although as Steve Langasek has pointed out, the Sarge-Etch upgrade will be hard unless the etch key becomes available to Sarge users who've not touched their system since Sarge r0a... I guess this comes down to making the etch key available in some kind of Sarge-signed repository, that you have to add as part of the Etch upgrade, and after which apt-key update will bring you up to Etch key currentness. I dont see a problem in requiring the user to get the key from the debian homepage whenever they want to verify a different distribution. What you can du is to have a Debian CA key, if you want to ship a trust anchor with the archives, but I dont see a need for it, since you need to verify it with other means anyway. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: Oh, the explanation for current practice is that if the key doesn't change in practice, apps that look at the keys won't cope well with the key changing, and when that becomes important, such as in the event of a compromise, we'll have major difficulties in coping. Lol, and we've seen that this week. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: No, a key is only as good as (a) how hard it is to break; and (b) how easy it is to trust. Key rotation helps make it harder to break (since the 2004 key won't do you much good now); and also forces us to consider how to make new keys easy to trust, which we otherwise might neglect. Looking at the parenthesis: the 2004 key would have been quite valuable a week ago. It could have been used to sign a fake 2005 key. Oh wait: *it still can be*. And once the 2004 key expires, that should mean that now I have no reason to trust the 2005 key. (Except for the fact that it's signed by AJT. But then, why not just use that as the archive key directly?) So you need something more than just I trust AJ. No one's worked out exactly what that should be yet. Yeah. I don't mean that rotation is bad, just that it seems at best only one small part of the puzzle, and it's not clear to me what the other parts should look like. Still, we can only put the puzzle together one piece at a time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: No, a key is only as good as (a) how hard it is to break; and (b) how easy it is to trust. Key rotation helps make it harder to break (since the 2004 key won't do you much good now); and also forces us to consider how to make new keys easy to trust, which we otherwise might neglect. Looking at the parenthesis: the 2004 key would have been quite valuable a week ago. It could have been used to sign a fake 2005 key. Oh wait: *it still can be*. It shouldn't be, since the 2004 key expired almost a year ago. Maybe we should be revoking expired keys as well. And once the 2004 key expires, that should mean that now I have no reason to trust the 2005 key. Sure you do: it's already on your disk. (Except for the fact that it's signed by AJT. But then, why not just use that as the archive key directly?) Because the archive key signs things automatically, and I'm not uploading my secret key to ftp-master and putting the passphrase into a script. Perhaps there are five phases we need to consider: (a) key is published, available for signing by developers, but unused (b) key is used to sign archive, along with previous key (c) key is used to sign archive alone (d) key is used to sign archive, along with next key (e) key is expired and/or revoked Any of those could be zero length. (a) might be useful for out of band authentication (I trust AJ, my book says the fingerprint should be...); (b)/(d) is useful for transitioning to new keys. At the moment (b) and (d) are around one month windows, maybe they should be longer. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
* Michael Vogt: Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Please try to get a new self-signature without an expiration data first. If they key is compromised, it has to be (manually) revoked anyway. Rotating it once per year doesn't make sense. At the very least, change the expiration data so that it doesn't fall into the holiday season. For stable, an offline key could be used. Maybe for stable-security, too. However, I don't think it's worth the trouble. If the key material is compromised because it is only, the attacker has already reached very central piece of Debian's infrastructure, and we lose even if the actual key material is stored off-line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Bernd Eckenfels: IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Yes, but it breaks a long term usage like web of trust. The Debian archive key does not take part in the web of trust. Anybody who has passed the OpenPGP NM checks should not sign that key. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Steve Langasek: For a user with a compromised local network, the only safe solution is to validate the new key via some web of trust. No, the web of trust doesn't solve the problem. I'm pretty sure most DDs don't even know who is authorized to issue a new archive key. A user has no way to judge which developers have sufficient knowledge to recognize a new, legitimate archive signing key. And so on, it's quite messy. The only reasonable answer at this stage is SSH-style leap of faith authentication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:15:08PM -0800, Thomas Bushnell BSG wrote: If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. I think I now understand better, and I can better express the uncertainty I was groping at. A key is only as good as the keys that sign it. The reason for rotating the key is that there is some non-zero risk that it will be compromised, and this limits exposure. But in order to validate the new key, which is only as good as its signatures, I must rely on whatever signs the new key. I trust AJ. So I trust AJ to sign the new key correctly. Surely, it seems to me, the risk of AJ allowing his own key to be compromised is just about the same as the risk of his allowing the archive key to be compromised. What am I missing? The exposure of the archive key is higher, because it sits on an Internet-connected, ssh-accessible server. Also, you don't have to trust AJ's key; in contrast with Florian's assessment of the NM-suitability of the three ftpmasters, one ftp assistant, and one RM who have signed this key so far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
* Steve Langasek: I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. Or publish a statement, maybe signed with your OpenPGP key, that the key 1024D/2D230C5F, fingerprint 084750FC01A6D388A643D869010908312D230C5F is the 2006 Debian archive key. This conveys more information than a certifying signature, and avoids the problem how you got physical ID for Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED], or a verification that the keyholder actually reads the mailbox mentioned in the user ID. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 02:04:49PM +0100, Florian Weimer wrote: * Steve Langasek: I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. Or publish a statement, maybe signed with your OpenPGP key, that the key 1024D/2D230C5F, fingerprint 084750FC01A6D388A643D869010908312D230C5F is the 2006 Debian archive key. This conveys more information than a certifying signature, and avoids the problem how you got physical ID for Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED], or a verification that the keyholder actually reads the mailbox mentioned in the user ID. 8-) Yes, that's also reasonable, although the downside is a lack of good distribution channel for such a signed statement -- key signatures you can throw at any keyserver and they'll stick. :) -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
Anthony Towns wrote: Oh, the explanation for current practice is that if the key doesn't change in practice, apps that look at the keys won't cope well with the key changing, and when that becomes important, such as in the event of a compromise, we'll have major difficulties in coping. In that case I suggest you rotate it every month for a few cycles. BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? Will stable even be installable anymore? How will the updated key be pushed out to stable quickly enough? Will we have to rebuild CDs and obsolete all the old ones then too? Is the current scheme of having overlapping signatures for 1 month long enough, given that stable users might well only update their machines quarterly or so? -- see shy jo [1] As is, for example, supposed to happen a month or so after etch is released. signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, 06 Jan 2006, Steve Langasek wrote: Yes, that's also reasonable, although the downside is a lack of good distribution channel for such a signed statement -- key signatures you can throw at any keyserver and they'll stick. :) [EMAIL PROTECTED] is a proper channel for such announcements as far as humans go. And I don't mean [EMAIL PROTECTED], I mean [EMAIL PROTECTED] OTOH, it would be nice to have automated key rollover working :) But I understand it is being worked on. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? On January 1 (or whenever a new key is issued) do a security update for stable on the package that has the keyring. [1] As is, for example, supposed to happen a month or so after etch is released. In this case we (well, not me...) can issue a new key that is valid from november 2006 (a month before etch is released) till october 2007. Use that key to sign the packages. Then the first year there will be no problems, unless the key is compromised. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ GnuPG key | http://maurits.vanrees.org/var/gpgkey.asc Do only what only you can do. --- Edsger Wybe Dijkstra signature.asc Description: Digital signature
Re: APT public key updates?
Maurits van Rees wrote: On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? On January 1 (or whenever a new key is issued) do a security update for stable on the package that has the keyring. That doesn't address most of the issues I raised. Just for example, debootstrap in d-i would not see the new key. -- see shy jo signature.asc Description: Digital signature
Re: APT public key updates?
Florian Weimer [EMAIL PROTECTED] wrote: Yes, but it breaks a long term usage like web of trust. The Debian archive key does not take part in the web of trust. Anybody who has passed the OpenPGP NM checks should not sign that key. Thats right, I was not refering to the usage as archive key, it was a general comment about trust concepts for key validation. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Joey Hess wrote: BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? Will stable even be installable anymore? How will the updated key be pushed out to stable quickly enough? Will we have to rebuild CDs and obsolete all the old ones then too? Is the current scheme of having overlapping signatures for 1 month long enough, given that stable users might well only update their machines quarterly or so? Given that stable is stable, wouldn't it be possible to sign each stable release with a special key kept offline without causing too much trouble? That doesn't solve security updates though, so the key for that would need to be updated as necessary. Alternatively, a two link process with a role key kept offline signing the archive key might be OK as well, but that leaves the question how not to have that key compromised. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: No, a key is only as good as (a) how hard it is to break; and (b) how easy it is to trust. Key rotation helps make it harder to break (since the 2004 key won't do you much good now); and also forces us to consider how to make new keys easy to trust, which we otherwise might neglect. Looking at the parenthesis: the 2004 key would have been quite valuable a week ago. It could have been used to sign a fake 2005 key. Oh wait: *it still can be*. It shouldn't be, since the 2004 key expired almost a year ago. Maybe we should be revoking expired keys as well. Sorry, I meant 2005. I forgot the new year; now I see the point you were making, and that makes sense to me. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 09:21:32AM -0500, Joey Hess wrote: Maurits van Rees wrote: On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: BTW, has anyone thought about what will happen when we have a stable release that has the 200n key in it and 200n+1 rolls around[1]? On January 1 (or whenever a new key is issued) do a security update for stable on the package that has the keyring. That doesn't address most of the issues I raised. Just for example, debootstrap in d-i would not see the new key. I thought I saw a reaction from someone else in a different part of the thread who thought that for people who install from an already burned CD set this wouldn't give problems, or only minor. I can't find that post though. Now I think about it more you are right that an expired key would give problems for people downloading a CD image that was originally signed with that key. In fact I think the same problem arises for a single package when the key of the developer of that package expires. Any package signed with the old key becomes untrusted, and should be regenerated, including the cd images. That would not be nice. Mind you, I am still using sarge at the moment, so I hardly have experience with signed packages. I'll go back to lurking now. ;) -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ GnuPG key | http://maurits.vanrees.org/var/gpgkey.asc Do only what only you can do. --- Edsger Wybe Dijkstra signature.asc Description: Digital signature
Re: APT public key updates?
Daniel Leidert wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 These are all notable in a) being RC b) not having any response from an apt maintainer -- see shy jo signature.asc Description: Digital signature
Re: APT public key updates?
x-post to deity list Am Donnerstag, den 05.01.2006, 15:02 -0500 schrieb Joey Hess: Daniel Leidert wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 These are all notable in a) being RC b) not having any response from an apt maintainer I know :( BTW: Why the source of apt isn't maintained any longer in CVS? A SVN repository doesn't seem to exist. Where is the current source maintained? Locally? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 03:02:05PM -0500, Joey Hess wrote: Daniel Leidert wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 These are all notable in a) being RC b) not having any response from an apt maintainer Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Cheers, Michael P.S. The source for debians apt is maintained with baz (package 'bazaar') at: http://people.debian.org/~mvo/arch/ in the [EMAIL PROTECTED]/apt--debian-sid--0 branch -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
[Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:13:06PM +0100, Michael Vogt wrote: These are all notable in a) being RC b) not having any response from an apt maintainer Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Does it mean we need new version of apt everytime when key changes? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? AIUI, Ubuntu isn't rotating their archive keys -- something else that their centralized model more readily affords them. I think they still have the same problem we do regarding how to cope with a key compromise revocation, though. -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
Steve Langasek [EMAIL PROTECTED] writes: AIUI, Ubuntu isn't rotating their archive keys -- something else that their centralized model more readily affords them. I'm a little confused about why we do rotate the keys. I'm not experienced in thinking through the subtle issues concerned, so I'm trying to learn, because I know that Debian has plenty of people who *do* have this experience, and I want to learn/understand. With a non-expiring key, there is the risk that the key will be compromised. However, with the expiring key, there is the risk that a fake key will be generated at the expected roll-over time. In other words, I needed to fetch the new key this week, from the web site, and tell my system yeah, that's the right key. Of course, the new key is signed with the old key. It's also signed with some sigs that I haven't checked, which I assume are the Debian ftpmasters. However, nothing about the apt-key procedure actually seems to have *checked* any of these signatures. Perhaps then we need to improve apt-key to implement a more careful model? If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Am I understanding rightly? missing something? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian archive keyring, so no update is needed when Debian keys change. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:26:41AM +0100, Bartosz Fenski aka fEnIo wrote: On Thu, Jan 05, 2006 at 11:13:06PM +0100, Michael Vogt wrote: These are all notable in a) being RC b) not having any response from an apt maintainer Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Does it mean we need new version of apt everytime when key changes? Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 for a proposal how the keys can be upgraded in the future. We certainly don't want new apt uploads just for that in the future. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? I uploaded a new apt that supports multiple signatures on the release file. The policy is that it needs at least one good signature and no bad signatures (but any number number of NO_PUBKEY signatures) to be considered trusted. It will still warn about missing keys but that's only fatal if no good signature was found. The upload also contains the new key in apts default keyring. This dosn't fix the key-upgrade problem yet. I outlined my proposal in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 Early testing (from incoming) is welcome :) Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu handles the archive keys with the mechanism described in #345891. Threre is a ubuntu-keyring package that contains the valid and no-longer valid server keys. apt-key update takes care of adding/removing the appropriate keys. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. If the 2006 key takes (say) 15 months to compromise, then it is fine to use it to sign and verify the new key on 1/1/2007, so long as you perform that verification before March... IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: AIUI, Ubuntu isn't rotating their archive keys -- something else that their centralized model more readily affords them. I'm a little confused about why we do rotate the keys. I'm not experienced in thinking through the subtle issues concerned, so I'm trying to learn, because I know that Debian has plenty of people who *do* have this experience, and I want to learn/understand. With a non-expiring key, there is the risk that the key will be compromised. However, with the expiring key, there is the risk that a fake key will be generated at the expected roll-over time. In other words, I needed to fetch the new key this week, from the web site, and tell my system yeah, that's the right key. Of course, the new key is signed with the old key. It's also signed with some sigs that I haven't checked, which I assume are the Debian ftpmasters. However, nothing about the apt-key procedure actually seems to have *checked* any of these signatures. There are four main attack vectors that I can see: - compromise of the user's local network connection - compromise of the user's local mirror - compromise of the PGP key, together with one of the preceding - compromise of ftp-master itself In the fourth case, either the compromise is detected by the admins, or it isn't. If it isn't, all bets are off: we can only ever have cryptographic assurance that the packages came from ftp-master, not that the packages that came from ftp-master are *good*, so we focus instead on prevention and detection of compromises instead and eliminate this case from consideration. If the compromise *is* detected by the admins, the key is revoked, the server is re-secured, and a new key is issued. So we know that our system has to deal with key revocations: providing means of both broadcasting the key revocation as widely as possible to users, and delivering a replacement key to those same users as securely as possible. In the third case, again the compromise is either detected, or it isn't. If it's detected, we're revoking the key again; if it's *not* detected (and it seems to me that anyone able to compromise the pgp key without also having to compromise ftp-master is likely good enough to go undetected), then this is a case where scheduled key rotations help us. It also shouldn't *hurt* us, since we need to have a sound process in place for dealing with key replacements regardless due to the possibility of compromise. The first two cases provide us with a rationale for wanting cryptographic assurances in the first place, and insight into what that assurance ought to look like. For a user with a compromised local mirror, just having the new key available to grab from http://ftp-master.debian.org is sufficient. (If it isn't, the user falls into one of the other categories.) For a user with a compromised local network, the only safe solution is to validate the new key via some web of trust. This is the feature that's missing today, to give Joe User some reasonable method of checking keys against the web of trust before importing them. Perhaps then we need to improve apt-key to implement a more careful model? Yes, I think so. I'm not sure that apt-key itself is what should be doing the checking, or if we should be giving users some sort of recipe for pre-verifying keys using gpg? $ gpg --recv-keys 2D230C5F gpg --update-trustdb \ gpg --batch --edit-key 2D230C5F quit 21 | grep -q 'validity: full' \ gpg --armor --export 2D230C5F | sudo apt-key add - If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. -- 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/ signature.asc Description: Digital signature
Re: APT public key updates?
Michael Vogt [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? I uploaded a new apt that supports multiple signatures on the release file. The policy is that it needs at least one good signature and no bad signatures (but any number number of NO_PUBKEY signatures) to be considered trusted. It will still warn about missing keys but that's only fatal if no good signature was found. The upload also contains the new key in apts default keyring. This dosn't fix the key-upgrade problem yet. I outlined my proposal in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 Early testing (from incoming) is welcome :) Wait a second. How will people download the new key using apt if apt refuses to download because it does not have the new key? And then what about the future? A stable release will not be upgradable if the key is not downloaded, but the key will not be downloadable. Or am i missing something? This whole thing sounds like a major problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Nick Phillips [EMAIL PROTECTED] wrote: If the 2006 key takes (say) 15 months to compromise, then it is fine to use it to sign and verify the new key on 1/1/2007, so long as you perform that verification before March... Or be able to proof the date of signing. IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Yes, but it breaks a long term usage like web of trust. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 05:22:44AM +0100, Bernd Eckenfels wrote: Nick Phillips [EMAIL PROTECTED] wrote: If the 2006 key takes (say) 15 months to compromise, then it is fine to use it to sign and verify the new key on 1/1/2007, so long as you perform that verification before March... Or be able to proof the date of signing. The only way to be confident the signing date is X/Y/ is to have had the key on that date -- otherwise someone can just set their clock back, sign it with that date, and pretend oh yeah, I did sign it then, I just forgot to upload. IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Yes, but it breaks a long term usage like web of trust. How so? In the long term you end up with aj signed 2005, aj and 2005 signed 2006, 2005 is expired; I don't think there's anything broken in that situation. We could potentially have the N key remain unexpired for the entire period the N+1 key is used; or maybe have overlapping keys, so that: 2006/01/01 - 2006/06/30: signed with 2006 key 2006/07/01 - 2006/12/31: signed with 2006 + 2007 key 2007/01/01 - 2007/06/30: signed with 2006 + 2007 key 2007/07/01 - 2007/12/31: signed with 2007 + 2008 key 2008/01/01 - 2008/06/30: signed with 2007 + 2008 key 2008/07/01 - 2008/12/31: signed with 2008 + 2009 key and in the event of a compromise, sign with: 2006, 2007, 2006-reissued, 2007-reissued on the basis that signing with the compromised 2006,2007 keys doesn't add security, but doesn't take it away either, and that the keys will be removed from the user's keyrings as part of a security update signed in the above manner. The above assumes keys represent one year, but are used for two years; having them represent 6 months instead would allow them to continue expiring after one year. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
Nick Phillips [EMAIL PROTECTED] writes: On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. If the 2006 key takes (say) 15 months to compromise, then it is fine to use it to sign and verify the new key on 1/1/2007, so long as you perform that verification before March... So we are worried about compromise by direct attack, rather than compromise by misplaced or stolen equipment/etc? It seems to me that this kind of computation depends intrinsically on how long it takes to compromise. If it takes eleven months, then we're currently screwed. It seems unlikely to me that this kind of analysis has taken place, which makes it unlikely that this is actually the explanation for our current practice. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns aj@azure.humbug.org.au writes: How so? In the long term you end up with aj signed 2005, aj and 2005 signed 2006, 2005 is expired; I don't think there's anything broken in that situation. So I do trust aj's keys, and the keys he signs. Unfortunately, I don't have any way to indicate that to apt-key or the keys automatically installed by the apt maintainer. Perhaps this needs to gel into a feature request for apt? Still, I don't fully understand why the rotation at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Steve Langasek [EMAIL PROTECTED] writes: For a user with a compromised local network, the only safe solution is to validate the new key via some web of trust. This is the feature that's missing today, to give Joe User some reasonable method of checking keys against the web of trust before importing them. I think I understand now. This is very helpful. So suppose I said that I trust keys sign by AJ Towns. I could then indicate that. Of course, I am now susceptible to any compromise of AJ's key, right? But that means that AJ should rotate his key too. How do I know which key is really AJs? By checking the signatures, from keys which could be compromised and so they should rotate. And so on, and so on. All of us need to start rotating all out keys in order for this to work. Another way to put the same point, inverted if you will, is to ask why it's ok to trust AJs non-rotating key, but not to trust a non-rotating archive key. If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. I think I now understand better, and I can better express the uncertainty I was groping at. A key is only as good as the keys that sign it. The reason for rotating the key is that there is some non-zero risk that it will be compromised, and this limits exposure. But in order to validate the new key, which is only as good as its signatures, I must rely on whatever signs the new key. I trust AJ. So I trust AJ to sign the new key correctly. Surely, it seems to me, the risk of AJ allowing his own key to be compromised is just about the same as the risk of his allowing the archive key to be compromised. What am I missing? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:04:32PM -0800, Thomas Bushnell BSG wrote: It seems to me that this kind of computation depends intrinsically on how long it takes to compromise. If it takes eleven months, then we're currently screwed. It seems unlikely to me that this kind of analysis has taken place, which makes it unlikely that this is actually the explanation for our current practice. Oh, the explanation for current practice is that if the key doesn't change in practice, apps that look at the keys won't cope well with the key changing, and when that becomes important, such as in the event of a compromise, we'll have major difficulties in coping. Cheers, aj signature.asc Description: Digital signature
Re: APT public key updates?
On Thu, Jan 05, 2006 at 07:38:37PM -0800, Steve Langasek wrote: In the third case, again the compromise is either detected, or it isn't. If it's detected, we're revoking the key again; if it's *not* detected (and it seems to me that anyone able to compromise the pgp key without also having to compromise ftp-master is likely good enough to go undetected), then this is a case where scheduled key rotations help us. There's also a secondary case where they help. Any PGP key can be cracked with sufficient outlay of computing power. Scheduled key rotations mean that this has a minimum *cost* requirement associated; it prevents mere time from being sufficient. If you work out the numbers carefully then you can effectively stop this attack for everybody who isn't rich enough to just hire away all the critical people and take control that way. Of course, the other requirement for this to work is that the new key not be generated until shortly before the old one is ready to expire. However, we don't have to do this annually; with a 2048-bit key, replacing every five years and generating the new key one year before the old one expires should be safe at present. That's a conservative estimate. To defend against ancillary attacks (like somebody grabbing a copy of the key from ftp-master) you need to know how probable they are, and reduce these figures accordingly. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: APT public key updates?
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: It seems to me that this kind of computation depends intrinsically on how long it takes to compromise. If it takes eleven months, then we're currently screwed. It seems unlikely to me that this kind of analysis has taken place, which makes it unlikely that this is actually the explanation for our current practice. The main reasons imho for expiring organisational keys are those: a) limit the revocation lists (n/a in this case, I guess) b) limit the lifetime of an exposed key (i.e. if ftpmaster leaves team) c) limit the lifetime in case of expected compromise of algorithms (the later is important in the long run, not in the year timescale we do it right now) Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:15:08PM -0800, Thomas Bushnell BSG wrote: But that means that AJ should rotate his key too. Yes. In theory I'd do that once every five years or so; in practice longer. :-/ Another way to put the same point, inverted if you will, is to ask why it's ok to trust AJs non-rotating key, but not to trust a non-rotating archive key. The archive key should rotate more often than my personal key because it's more vulnerable. An additional reason to rotate it is that it's possessed by different people -- in 2004, it could be accessed by ftpmaster (James, Ryan, Randall, Dan, Mike and me) and by various DSA folks (Wichert and Joey, in particular I think); this year's can be accessed by ftpmaster by not ftp assistants (so James, Ryan and me), and DSA folks. Key rotation (whether scheduled or unscheduled) is the only way to ensure people's authorisation can actually be revoked. I think I now understand better, and I can better express the uncertainty I was groping at. A key is only as good as the keys that sign it. No, a key is only as good as (a) how hard it is to break; and (b) how easy it is to trust. Key rotation helps make it harder to break (since the 2004 key won't do you much good now); and also forces us to consider how to make new keys easy to trust, which we otherwise might neglect. But in order to validate the new key, which is only as good as its signatures, I must rely on whatever signs the new key. There are out of band ways too; if you trust publishers to not be trying to actively exploit you, you can look at fingerprints published in a book; if you trust that your ISP is pretty reliable, you might be confident that http://ftp-master.d.o/ziyi_key_2006.asc is actually what it should be; if you trust that any attacker is going to have limited power, you might be confident that looking at a variety of books, or downloading the key from a variety of ISPs on different days will only result in the same fingerprint if it's the correct one. I trust AJ. So I trust AJ to sign the new key correctly. You can also look at James', Ryan's or Steve's signature on the key, and trust that they've verified it appropriately, if you trust them. Surely, it seems to me, the risk of AJ allowing his own key to be compromised is just about the same as the risk of his allowing the archive key to be compromised. What am I missing? That one day I might not be ftpmaster, so you'll need some other way to verify the next key we put out -- whether due to an annual rotation, an actual compromise, a key length upgrade, a potential compromise, catastrophic data loss, or some other reason. So you need something more than just I trust AJ. No one's worked out exactly what that should be yet. Cheers, aj signature.asc Description: Digital signature
APT public key updates?
When I try to upgrade one of my machines running testing, I get a warning about a missing public key: [...] W: GPG error: http://ftp.no.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F W: You may want to run apt-get update to correct these problems [...] Do you want to continue? [Y/n/?] WARNING: untrusted versions of the following packages will be installed! Untrusted packages could compromise your system's security. You should only proceed with the installation if you are certain that this is what you want to do. [...] I guess this is not how every GPG key change for the archive is supposed to be handled, as I would expect key updates to happen mostly automatic. Where can I find information on what went wrong with my installation, and what the correct procedure is to fix it when this problem arises. I'm glad it does not happen to several hundred production machines, and just my test machine. I worked around the problem using this formula, but expect there must be a more sensible way to handle public key updates: gpg --recv-key 010908312D230C5F gpg -a --export 2D230C5F | apt-key add - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Am Donnerstag, den 05.01.2006, 00:03 +0100 schrieb Petter Reinholdtsen: When I try to upgrade one of my machines running testing, I get a warning about a missing public key: [...] W: GPG error: http://ftp.no.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F [snip] See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
