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,
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
Way to go Joey - well demonstrated :)
Andy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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;
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
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
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
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
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
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?
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
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
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
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
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
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
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]
* 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
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
* 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
* 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
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...
[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
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
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
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
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
* 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
* 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
* 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
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
* 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
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
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
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
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
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
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,
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
65 matches
Mail list logo
