diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110131/002401.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110131/002401.html | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110131/002401.html b/zarb-ml/mageia-dev/20110131/002401.html new file mode 100644 index 000000000..fc1af8cdb --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002401.html @@ -0,0 +1,120 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] PGP keys and package signing + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C201101312042.44309.maarten.vanraes%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002399.html"> + <LINK REL="Next" HREF="002402.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] PGP keys and package signing</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C201101312042.44309.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] PGP keys and package signing">maarten.vanraes at gmail.com + </A><BR> + <I>Mon Jan 31 20:42:44 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002399.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002402.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2401">[ date ]</a> + <a href="thread.html#2401">[ thread ]</a> + <a href="subject.html#2401">[ subject ]</a> + <a href="author.html#2401">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op maandag 31 januari 2011 20:12:24 schreef nicolas vigier: +><i> On Mon, 31 Jan 2011, Michael Scherer wrote: +</I>><i> > Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit : +</I>><i> > > On Mon, 31 Jan 2011, Michael Scherer wrote: +</I>><i> > > > We can 1) have a long enough expiration date ( but EOL + 1y seems +</I>><i> > > > quite enough IMHO ) +</I>><i> > > > 2) push unexpired keys before it is too late if needed ( I routinely +</I>><i> > > > push my key after extending the expiration date ). +</I>><i> > > +</I>><i> > > Pushing new unexpired keys also means we need to resign all old +</I>><i> > > packages if we want them to be installable. So that's not something we +</I>><i> > > want to do too often if it's not needed. +</I>><i> > +</I>><i> > Nope, I didn't say "new unexpired key", but just push the same key, with +</I>><i> > the expiration date extended. That should be painless IIRC ( at least, +</I>><i> > it is for me ). +</I>><i> +</I>><i> Oh, I misunderstood this as I imagined it was not possible to change +</I>><i> expiration date on a key as it would be difficult to check if the change +</I>><i> was done before expiration. But after checking, it is indeed possible, +</I>><i> and it is even possible to do it after the expiration date. +</I>><i> +</I>><i> So we can do it, but we should remember that it does not protect against +</I>><i> a key compromised after it has expired (as someone stealing the key +</I>><i> can change the expiration date even after it has expired). +</I>><i> +</I>><i> So the only use of expiration date I see is to check that the key was +</I>><i> updated from keyserver recently. Maybe we can set a short expiration +</I>><i> time (15 days ?), and have something in cron to update it a few days +</I>><i> before it expire ? +</I>><i> +</I>><i> > > > > - I don't think using expiration date reduce the damage of a +</I>><i> > > > > leaked +</I>><i> > > > > +</I>><i> > > > > key. If the key is leaked, we revoke it (or its signature) +</I>><i> > > > > immediatly on all key servers, which should be faster than +</I>><i> > > > > waiting for the key to expire. And replacing an expired key is +</I>><i> > > > > not more simple than replacing a revoked key. +</I>><i> > > > +</I>><i> > > > The problem is not leaking the key, it is about cryptographic attacks +</I>><i> > > > about older keys. +</I>><i> > > > +</I>><i> > > > If in 10 years, there is some technology that allows people to get +</I>><i> > > > our private key by bruteforce on the public one, if it is expired, +</I>><i> > > > attackers will not be able to use it even if they have it. Since the +</I>><i> > > > plan is to say "every key signed is valid", then we are potentially +</I>><i> > > > screwed if a old key is compromised offline. +</I>><i> > > +</I>><i> > > If in 10 years there is some technology to get our private key, then +</I>><i> > > it's still possible to revoke the key at that time. +</I>><i> > > +</I>><i> > > Instead of deciding +</I>><i> > > now that the key will expire in a few years, I would prefer that we +</I>><i> > > look at it in a few years to decide if we want to revoke it. +</I>><i> > +</I>><i> > Wouldn't it be too late ? +</I>><i> +</I>><i> Considering that it is possible to update expiration date even after it +</I>><i> has expired, this expiration date doesn't protect against some technology +</I>><i> that would allow people in the futur to bruteforce the private key. +</I> + +what if there is no network access? keyservers are nice, but an isolated +install should still be possible... +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002399.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002402.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2401">[ date ]</a> + <a href="thread.html#2401">[ thread ]</a> + <a href="subject.html#2401">[ subject ]</a> + <a href="author.html#2401">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |