diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110131/002399.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110131/002399.html | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110131/002399.html b/zarb-ml/mageia-dev/20110131/002399.html new file mode 100644 index 000000000..6cacf13c3 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002399.html @@ -0,0 +1,110 @@ +<!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=%3C1296502627.12892.132.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002398.html"> + <LINK REL="Next" HREF="002401.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] PGP keys and package signing</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C1296502627.12892.132.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] PGP keys and package signing">misc at zarb.org + </A><BR> + <I>Mon Jan 31 20:37:07 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002401.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2399">[ date ]</a> + <a href="thread.html#2399">[ thread ]</a> + <a href="subject.html#2399">[ subject ]</a> + <a href="author.html#2399">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 31 janvier 2011 à 20:12 +0100, nicolas vigier a écrit : +><i> On Mon, 31 Jan 2011, Michael Scherer wrote: +</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> +But we would notice it, I guess. That could be a good idea to check if +any of our old key do not appear on the keyring with a non expired +date :) + +><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> +Or maybe we can keep the expiration date to indicate when the key should +not be used anymore ( ie, as a indication, nothing more, as we cannot +guarantee anything ), and once the expiration date occurs ( expiration +date set on our copy of the key ), we upload the revocation certificate +( with we == a cronjob , by checking the date of the key ) + +We could even use this on client side to indicate that a release is no +longer supported. ( ie, DRY principle ). + +><i> > > Instead of deciding +</I>><i> > > now that the key will expire in a few years, I would prefer that we look +</I>><i> > > 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> +It is up to the tool to use or not the expiration. Ie, if we tell to +urpmi "do not trust expired key", we can as well say "keep a list of key +that have expired and never trust a key, even if it say the contrary". + +But indeed, that doesn't sound very secure per se :/ + +-- +Michael Scherer + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002401.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2399">[ date ]</a> + <a href="thread.html#2399">[ thread ]</a> + <a href="subject.html#2399">[ subject ]</a> + <a href="author.html#2399">[ 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> |