From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110131/002380.html | 144 +++++++++++++++++++++ zarb-ml/mageia-dev/20110131/002381.html | 109 ++++++++++++++++ zarb-ml/mageia-dev/20110131/002382.html | 87 +++++++++++++ zarb-ml/mageia-dev/20110131/002383.html | 84 ++++++++++++ zarb-ml/mageia-dev/20110131/002384.html | 83 ++++++++++++ zarb-ml/mageia-dev/20110131/002385.html | 99 ++++++++++++++ zarb-ml/mageia-dev/20110131/002386.html | 85 ++++++++++++ zarb-ml/mageia-dev/20110131/002387.html | 111 ++++++++++++++++ zarb-ml/mageia-dev/20110131/002388.html | 175 +++++++++++++++++++++++++ zarb-ml/mageia-dev/20110131/002389.html | 134 +++++++++++++++++++ zarb-ml/mageia-dev/20110131/002390.html | 70 ++++++++++ zarb-ml/mageia-dev/20110131/002391.html | 76 +++++++++++ zarb-ml/mageia-dev/20110131/002392.html | 79 ++++++++++++ zarb-ml/mageia-dev/20110131/002393.html | 125 ++++++++++++++++++ zarb-ml/mageia-dev/20110131/002394.html | 134 +++++++++++++++++++ zarb-ml/mageia-dev/20110131/002395.html | 81 ++++++++++++ zarb-ml/mageia-dev/20110131/002396.html | 144 +++++++++++++++++++++ zarb-ml/mageia-dev/20110131/002397.html | 154 ++++++++++++++++++++++ zarb-ml/mageia-dev/20110131/002398.html | 117 +++++++++++++++++ zarb-ml/mageia-dev/20110131/002399.html | 110 ++++++++++++++++ zarb-ml/mageia-dev/20110131/002400.html | 90 +++++++++++++ zarb-ml/mageia-dev/20110131/002401.html | 120 +++++++++++++++++ zarb-ml/mageia-dev/20110131/002402.html | 73 +++++++++++ zarb-ml/mageia-dev/20110131/002403.html | 70 ++++++++++ zarb-ml/mageia-dev/20110131/002404.html | 69 ++++++++++ zarb-ml/mageia-dev/20110131/002422.html | 71 ++++++++++ zarb-ml/mageia-dev/20110131/author.html | 177 +++++++++++++++++++++++++ zarb-ml/mageia-dev/20110131/date.html | 177 +++++++++++++++++++++++++ zarb-ml/mageia-dev/20110131/index.html | 1 + zarb-ml/mageia-dev/20110131/subject.html | 177 +++++++++++++++++++++++++ zarb-ml/mageia-dev/20110131/thread.html | 215 +++++++++++++++++++++++++++++++ 31 files changed, 3441 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110131/002380.html create mode 100644 zarb-ml/mageia-dev/20110131/002381.html create mode 100644 zarb-ml/mageia-dev/20110131/002382.html create mode 100644 zarb-ml/mageia-dev/20110131/002383.html create mode 100644 zarb-ml/mageia-dev/20110131/002384.html create mode 100644 zarb-ml/mageia-dev/20110131/002385.html create mode 100644 zarb-ml/mageia-dev/20110131/002386.html create mode 100644 zarb-ml/mageia-dev/20110131/002387.html create mode 100644 zarb-ml/mageia-dev/20110131/002388.html create mode 100644 zarb-ml/mageia-dev/20110131/002389.html create mode 100644 zarb-ml/mageia-dev/20110131/002390.html create mode 100644 zarb-ml/mageia-dev/20110131/002391.html create mode 100644 zarb-ml/mageia-dev/20110131/002392.html create mode 100644 zarb-ml/mageia-dev/20110131/002393.html create mode 100644 zarb-ml/mageia-dev/20110131/002394.html create mode 100644 zarb-ml/mageia-dev/20110131/002395.html create mode 100644 zarb-ml/mageia-dev/20110131/002396.html create mode 100644 zarb-ml/mageia-dev/20110131/002397.html create mode 100644 zarb-ml/mageia-dev/20110131/002398.html create mode 100644 zarb-ml/mageia-dev/20110131/002399.html create mode 100644 zarb-ml/mageia-dev/20110131/002400.html create mode 100644 zarb-ml/mageia-dev/20110131/002401.html create mode 100644 zarb-ml/mageia-dev/20110131/002402.html create mode 100644 zarb-ml/mageia-dev/20110131/002403.html create mode 100644 zarb-ml/mageia-dev/20110131/002404.html create mode 100644 zarb-ml/mageia-dev/20110131/002422.html create mode 100644 zarb-ml/mageia-dev/20110131/author.html create mode 100644 zarb-ml/mageia-dev/20110131/date.html create mode 120000 zarb-ml/mageia-dev/20110131/index.html create mode 100644 zarb-ml/mageia-dev/20110131/subject.html create mode 100644 zarb-ml/mageia-dev/20110131/thread.html (limited to 'zarb-ml/mageia-dev/20110131') diff --git a/zarb-ml/mageia-dev/20110131/002380.html b/zarb-ml/mageia-dev/20110131/002380.html new file mode 100644 index 000000000..3caf49bf7 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002380.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 04:16:43 CET 2011 +

+
+ +
Hello,
+
+Now that we have a working build system, we need to setup the last part,
+which is package signing. And for this we need a GPG key. So it's time
+to decide on some policy about PGP keys.
+
+We can look at how it was done at Mandriva. If I remember correctly :
+ - cooker packages were signed with a key stored on the build system
+ - stable release packages were signed at release time with an other
+   key, not stored on the build system, but stored on the server used
+   to prepare the release and generate the ISOs
+ - updates for main repository were managed by secteam, and signed by
+   secteam key. The secteam didn't use the build system but their own
+   servers, so the key was stored on their servers
+ - updates for contrib repository were signed using a key stored on the
+   build system
+ - backports for main and contrib repository were signed using a key
+   stored on the build system
+
+However there are a few problems with this :
+ - too many different keys, with different names, it's difficult to see
+   which ones are really official. 
+ - keys stored on the build system were not secure (all contributors and
+   apprentice had shell access on the build system and could easily become
+   root using iurt or other techniques, and then access the secret keys).
+   We won't provide shell access on the same servers as the build system
+   so it should be more secure, however it is always possible that a
+   server be compromised, with all the pgp keys on it, so we should plan
+   for it, and be able to revoke keys if it happens
+ - using a different key for developement version, and released version
+   means we need to resign all packages for the release, taking a lot
+   of time, cpu, and bandwidth to copy the packages between different
+   servers
+ - updates will be done using the same build system, so there is no use
+   to have two different keys for release and updates packages
+ - signed packages are supposed to prevent someone from modifying
+   packages on the mirrors. However the public key used to verify the
+   packages is downloaded from the mirror, and could be modified too.
+   So it would be very easy to create a fake mirror with modified
+   packages. We should fix that by allowing only trusted keys to be used.
+
+
+So I propose that we use two keys :
+ - We sign all packages from all repositories using only one key. This
+   key is stored on the buildsystem. We can call it packages at mageia.org.
+ - We have an other key, that we call board at mageia.org. This key is
+   not used on any online server, and is supposed to never be changed,
+   and should not be compromised. Only a few people have a copy of this
+   key (some people from board ?), kept on a usb key hidden somewhere, but
+   not on their laptop or any computer with internet connection. This key
+   is used to sign the key packages at mageia.org (and revoke it if needed),
+   and other official keys of the project, but never used for anything
+   else (not for receiving encrypted messages). And the signature is
+   sent on public keyservers.
+ - We add the board at mageia.org public key inside the urpmi package. 
+   We change urpmi so that it refuses to use any key which has not been
+   signed by board at mageia.org. And urpmi should frequently update the
+   keys it is using from public keyservers to check that its signature
+   from board@ has not been revoked (or that the key self signature has
+   not been revoked).
+ - In case we think the packages@ key may have been compromised, or is
+   too old, or we want to change it for any other reason, we revoke the
+   key, and/or revoke the signature from board@ so that it is no
+   longer accepted by urpmi. We create a new key, we sign it with
+   the board@ key and we can start to use this new key.
+
+According to this page :
+http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html
+there is also a few things we need to improve in urpmi to make it more
+secure (signed hdlists, and expiration dates on hdlists), but this is
+for later.
+
+In this thread :
+https://www.mageia.org/pipermail/mageia-dev/20110128/002363.html
+misc proposed that we publish tarballs of our software on the mirrors,
+and sign them using a pgp key. So we need a key for that. We also want
+to sign ISOs, maybe with a different key. So I think we can do the same
+as for packages key, we create new keys for software releases and for
+ISOs, and we sign those keys with the board@ key. And we can tell
+everybody that all files released by the project are always signed by
+a key that was signed by the board@ key.
+
+If we decide to do this, someone from board could generate the key next
+week at fosdem after the election, save it on usb key for other board
+members, and give the fingerprint to everybody to sign the key.
+
+Any opinions on this ? Or other ideas ? Or comments ?
+
+Nicolas
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002381.html b/zarb-ml/mageia-dev/20110131/002381.html new file mode 100644 index 000000000..3fabfb10e --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002381.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Motoko-chan + motokochan at animeneko.net +
+ Mon Jan 31 05:16:36 CET 2011 +

+
+ +
On 01/30/2011 07:16 PM, nicolas vigier wrote:
+> So I propose that we use two keys :
+>   - We sign all packages from all repositories using only one key. This
+>     key is stored on the buildsystem. We can call it packages at mageia.org.
+Sounds good to me.
+
+>   - We have an other key, that we call board at mageia.org. This key is
+>     not used on any online server, and is supposed to never be changed,
+>     and should not be compromised. Only a few people have a copy of this
+>     key (some people from board ?), kept on a usb key hidden somewhere, but
+>     not on their laptop or any computer with internet connection. This key
+>     is used to sign the key packages at mageia.org (and revoke it if needed),
+>     and other official keys of the project, but never used for anything
+>     else (not for receiving encrypted messages). And the signature is
+>     sent on public keyservers.
+If possible, using a split key so that no single person can revoke a 
+signature or sign a key would be useful. This would prevent attacks 
+where an individual might be tricked into signing an attacker's key. It 
+would require multiple people to be tricked or have their systems 
+compromised to have that key compromised.
+
+
+>   - We add the board at mageia.org public key inside the urpmi package.
+>     We change urpmi so that it refuses to use any key which has not been
+>     signed by board at mageia.org. And urpmi should frequently update the
+>     keys it is using from public keyservers to check that its signature
+>     from board@ has not been revoked (or that the key self signature has
+>     not been revoked).
+What about third-party repositories, like PLF is to Mandriva? Making 
+that change would require that each of those repository owners have 
+their key signed to work with the urpmi framework. This could either 
+mean the death of urpmi for managing packages, diluting the trust of the 
+board@ key, or discouraging outside contributions.
+
+What if urpmi automatically trusts packages signed with a key signed by 
+board@ and prompt on the first install of a package that is signed by a 
+different key? The yum tool used by Fedora, RHEL, and CentOS works very 
+well by prompting on new keys.
+
+
+>   - In case we think the packages@ key may have been compromised, or is
+>     too old, or we want to change it for any other reason, we revoke the
+>     key, and/or revoke the signature from board@ so that it is no
+>     longer accepted by urpmi. We create a new key, we sign it with
+>     the board@ key and we can start to use this new key.
+Sounds good. I'd almost suggest a new packages signing key for each new 
+release that is valid for the supported life of the release plus one 
+year. It's a bit more work, but would reduce the damage a key leak would 
+cause. Unfortunately, this would bring back the problems of re-signing 
+packages when they are turned into a release.
+
+  - Michael
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002382.html b/zarb-ml/mageia-dev/20110131/002382.html new file mode 100644 index 000000000..67276d225 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002382.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] BS down + + + + + + + + + +

[Mageia-dev] BS down

+ Thomas Backlund + tmb at iki.fi +
+ Mon Jan 31 09:21:09 CET 2011 +

+
+ +
Pascal Terjan skrev 31.1.2011 00:54:
+>
+> All packages have been rebuild, BS should be back in its original state
+>
+
+Have you also re-enabled youri reuploading check ?
+
+--
+Thomas
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002383.html b/zarb-ml/mageia-dev/20110131/002383.html new file mode 100644 index 000000000..016831140 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002383.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] [Mageia-sysadm] Accident + + + + + + + + + +

[Mageia-dev] [Mageia-sysadm] Accident

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 31 09:49:52 CET 2011 +

+
+ +
On 29 January 2011 20:58, Pascal Terjan <pterjan at gmail.com> wrote:
+> Sorry everyone, while removing my tests run on valstar, as that's not
+> the best place for tests, I removed bootsrap repository :(
+> I have stopped the build system and Nanar is sending back his copy of
+> the repository.
+
+So you really want to be slaped with chains on every BS you touch :-) ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002384.html b/zarb-ml/mageia-dev/20110131/002384.html new file mode 100644 index 000000000..ff88a9818 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002384.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] BS down + + + + + + + + + +

[Mageia-dev] BS down

+ Pascal Terjan + pterjan at gmail.com +
+ Mon Jan 31 10:53:39 CET 2011 +

+
+ +
On Mon, Jan 31, 2011 at 08:21, Thomas Backlund <tmb at iki.fi> wrote:
+> Pascal Terjan skrev 31.1.2011 00:54:
+>>
+>> All packages have been rebuild, BS should be back in its original state
+>>
+>
+> Have you also re-enabled youri reuploading check ?
+
+Yes that's what I mean by "BS should be back in its original state"
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002385.html b/zarb-ml/mageia-dev/20110131/002385.html new file mode 100644 index 000000000..dca8a8c52 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002385.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Remy CLOUARD + shikamaru at mandriva.org +
+ Mon Jan 31 12:02:33 CET 2011 +

+
+ +
On Sun, Jan 30, 2011 at 08:16:36PM -0800, Motoko-chan wrote:
+> On 01/30/2011 07:16 PM, nicolas vigier wrote:
+[...]
+> >  - We add the board at mageia.org public key inside the urpmi package.
+> >    We change urpmi so that it refuses to use any key which has not been
+> >    signed by board at mageia.org. And urpmi should frequently update the
+> >    keys it is using from public keyservers to check that its signature
+> >    from board@ has not been revoked (or that the key self signature has
+> >    not been revoked).
+> What about third-party repositories, like PLF is to Mandriva? Making
+> that change would require that each of those repository owners have
+> their key signed to work with the urpmi framework. This could either
+> mean the death of urpmi for managing packages, diluting the trust of
+> the board@ key, or discouraging outside contributions.
+> 
+Well, not necessarily, third party repos could just provide their keys
+and describe how users should import it. AFAIK, that’s what’s done on
+Fedora side with the rpmfusion repo.
+> What if urpmi automatically trusts packages signed with a key signed
+> by board@ and prompt on the first install of a package that is
+> signed by a different key? The yum tool used by Fedora, RHEL, and
+> CentOS works very well by prompting on new keys.
+> 
+I’ve never used guis on Fedora, but for me you could as well install the
+rpm containing the third party keys with yum and the --nogpgcheck
+switch.
+
+I guess this option should be implemented in urpmi for that to work on
+our side.
+
+Regards,
+-- 
+Rémy CLOUARD
+() ascii ribbon campaign - against html e-mail
+/\ www.asciiribbon.org - against proprietary attachments
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 230 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110131/b3308c6b/attachment.asc>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002386.html b/zarb-ml/mageia-dev/20110131/002386.html new file mode 100644 index 000000000..8417bccf2 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002386.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Christophe Fergeau + cfergeau at gmail.com +
+ Mon Jan 31 12:13:04 CET 2011 +

+
+ +
Hey,
+
+2011/1/31 nicolas vigier <boklm at mars-attacks.org>:
+>  - In case we think the packages@ key may have been compromised, or is
+>   too old, or we want to change it for any other reason, we revoke the
+>   key, and/or revoke the signature from board@ so that it is no
+>   longer accepted by urpmi. We create a new key, we sign it with
+>   the board@ key and we can start to use this new key.
+
+Will all existing packages be reviewed and resigned when they key is
+thought to have been compromised? What happens on user systems when
+this is done? Will they have to reinstall all packages signed with the
+new key?
+
+Christophe
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002387.html b/zarb-ml/mageia-dev/20110131/002387.html new file mode 100644 index 000000000..12f573a9f --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002387.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Olivier Thauvin + nanardon at nanardon.zarb.org +
+ Mon Jan 31 12:43:17 CET 2011 +

+
+ +
* Christophe Fergeau (cfergeau at gmail.com) wrote:
+> Hey,
+> 
+> 2011/1/31 nicolas vigier <boklm at mars-attacks.org>:
+> >  - In case we think the packages@ key may have been compromised, or is
+> >   too old, or we want to change it for any other reason, we revoke the
+> >   key, and/or revoke the signature from board@ so that it is no
+> >   longer accepted by urpmi. We create a new key, we sign it with
+> >   the board@ key and we can start to use this new key.
+> 
+> Will all existing packages be reviewed and resigned when they key is
+> thought to have been compromised? What happens on user systems when
+> this is done? Will they have to reinstall all packages signed with the
+> new key?
+
+Re-signing packages will not change their name-evr-arch, so on urpmi/rpm
+side packages does not have to be updated. But from a user point of view
+they installed packages (then checked it) before the compromission, ie
+when packages were trustable.
+
+So in case of compromission packages must be resigned but I don't think
+users have to reinstall it as their content won't changes.
+
+In the case a packages is compromised (a package with malware is
+introduced on the mirror) then we'll have to provide an update with a
+clean package and in this specific case users will have to update it.
+
+> 
+> Christophe
+-- 
+
+Olivier Thauvin
+CNRS  -  LATMOS
+♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 197 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110131/4b41d3ff/attachment.asc>
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002388.html b/zarb-ml/mageia-dev/20110131/002388.html new file mode 100644 index 000000000..45c8e9f3b --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002388.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 31 15:57:14 CET 2011 +

+
+ +
Le lundi 31 janvier 2011 à 04:16 +0100, nicolas vigier a écrit :
+> Hello,
+> 
+> Now that we have a working build system, we need to setup the last part,
+> which is package signing. And for this we need a GPG key. So it's time
+> to decide on some policy about PGP keys.
+>
+
+>  - keys stored on the build system were not secure (all contributors and
+>    apprentice had shell access on the build system and could easily become
+>    root using iurt or other techniques, and then access the secret keys).
+
+Mhh, the keys are stored on raoh, and no one except few selected people
+had access ( granted, there was some flaws since I know someone who
+managed to get access one day despite not being authorized ).
+
+
+> So I propose that we use two keys :
+>  - We sign all packages from all repositories using only one key. This
+>    key is stored on the buildsystem. We can call it packages at mageia.org.
+>  - We have an other key, that we call board at mageia.org. This key is
+>    not used on any online server, and is supposed to never be changed,
+>    and should not be compromised. Only a few people have a copy of this
+>    key (some people from board ?), kept on a usb key hidden somewhere, but
+>    not on their laptop or any computer with internet connection. This key
+>    is used to sign the key packages at mageia.org (and revoke it if needed),
+>    and other official keys of the project, but never used for anything
+>    else (not for receiving encrypted messages). And the signature is
+>    sent on public keyservers.
+
+If we want to sign the key, we will have a network connection, no ?
+
+
+>  - We add the board at mageia.org public key inside the urpmi package. 
+>    We change urpmi so that it refuses to use any key which has not been
+>    signed by board at mageia.org. And urpmi should frequently update the
+>    keys it is using from public keyservers to check that its signature
+>    from board@ has not been revoked (or that the key self signature has
+>    not been revoked).
+
+>  - In case we think the packages@ key may have been compromised, or is
+>    too old, or we want to change it for any other reason, we revoke the
+>    key, and/or revoke the signature from board@ so that it is no
+>    longer accepted by urpmi. We create a new key, we sign it with
+>    the board@ key and we can start to use this new key.
+
+Since computer get faster days and days ( until the days you buy them ),
+and there is new cryptographic techniques found each year. So it seems
+to me quite sane to change the keys every 2/3 years. More often mean
+that we will forget how we did, and too often could be bad ( even if
+IMHO, one key per release would be nice but maybe overkill ). 
+
+This way, we can check the procedure is working, we will have a robust
+key, following up to date requirements of security. And we can fix
+problem if any without having the pressure of "the key got compromised".
+
+
+
+> In this thread :
+> https://www.mageia.org/pipermail/mageia-dev/20110128/002363.html
+> misc proposed that we publish tarballs of our software on the mirrors,
+> and sign them using a pgp key. So we need a key for that. We also want
+> to sign ISOs, maybe with a different key. So I think we can do the same
+> as for packages key, we create new keys for software releases and for
+> ISOs, and we sign those keys with the board@ key. And we can tell
+> everybody that all files released by the project are always signed by
+> a key that was signed by the board@ key.
+
+Yup. I would also go on making sure the key is signed ( web of trust,
+etc ).
+
+> If we decide to do this, someone from board could generate the key next
+> week at fosdem after the election, save it on usb key for other board
+> members, and give the fingerprint to everybody to sign the key.
+
+I would rather make sure that the key cannot be used by only one board
+member. Not that I do not trust people for that ( they are the board
+after all ), but it would be safer to have it distributed and resilient
+if someone steal the key ( like a burglar, etc ). 
+
+Maybe have it password protected should be sufficient ( except if people
+forget that password, or stick it to the key ). 
+
+Pascal proposed to use https://store.ironkey.com/personal , on the
+thread
+https://www.mageia.org/pipermail/mageia-sysadm/2011-January/002155.html
+
+Another last solution to prevent theft would to use shamir secret
+sharing ( as also said in the other thread, but maybe I am too insistant
+on this wonderful cryptographic invention ). This way, people would have
+to steal several part of the file to get something usable.
+( for Harry Potter fan, think of horcruxes )
+
+
+And also, I think we should routinely make sure the key is readable
+( ie, that people know where it is, and the support is still good ), so
+we do not discover one day that half the key keeper lost the key while
+moving, thinking someone else had it, and the other half stored it near
+magnet, rendering it unreadable.
+
+And make sure the key is not sent as cleartext on the web too.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002389.html b/zarb-ml/mageia-dev/20110131/002389.html new file mode 100644 index 000000000..2f189a0d5 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002389.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 16:03:55 CET 2011 +

+
+ +
On Sun, 30 Jan 2011, Motoko-chan wrote:
+
+> On 01/30/2011 07:16 PM, nicolas vigier wrote:
+>> So I propose that we use two keys :
+>>   - We sign all packages from all repositories using only one key. This
+>>     key is stored on the buildsystem. We can call it packages at mageia.org.
+> Sounds good to me.
+>
+>>   - We have an other key, that we call board at mageia.org. This key is
+>>     not used on any online server, and is supposed to never be changed,
+>>     and should not be compromised. Only a few people have a copy of this
+>>     key (some people from board ?), kept on a usb key hidden somewhere, but
+>>     not on their laptop or any computer with internet connection. This key
+>>     is used to sign the key packages at mageia.org (and revoke it if needed),
+>>     and other official keys of the project, but never used for anything
+>>     else (not for receiving encrypted messages). And the signature is
+>>     sent on public keyservers.
+> If possible, using a split key so that no single person can revoke a 
+> signature or sign a key would be useful. This would prevent attacks where 
+> an individual might be tricked into signing an attacker's key. It would 
+> require multiple people to be tricked or have their systems compromised to 
+> have that key compromised.
+
+Yes, we could do something like that. Maybe each board member could have
+a copy of the key, but encrypted with the key of all other board members,
+so that it requires two people to access the key ? Or the people who
+have the key don't know the passphrase, and the people who know the
+passphrase don't have the key ?
+However we should also try to do something simple, to avoid losing
+access to the key because it's too complicate.
+
+>>   - We add the board at mageia.org public key inside the urpmi package.
+>>     We change urpmi so that it refuses to use any key which has not been
+>>     signed by board at mageia.org. And urpmi should frequently update the
+>>     keys it is using from public keyservers to check that its signature
+>>     from board@ has not been revoked (or that the key self signature has
+>>     not been revoked).
+> What about third-party repositories, like PLF is to Mandriva? Making that 
+> change would require that each of those repository owners have their key 
+> signed to work with the urpmi framework. This could either mean the death 
+> of urpmi for managing packages, diluting the trust of the board@ key, or 
+> discouraging outside contributions.
+>
+> What if urpmi automatically trusts packages signed with a key signed by 
+> board@ and prompt on the first install of a package that is signed by a 
+> different key? The yum tool used by Fedora, RHEL, and CentOS works very 
+> well by prompting on new keys.
+
+For PLF packages, they will now be included on Mageia repository, so
+most users should not need to use external repositories. However we
+can add an option or prompt to disable this check, or an option to
+manually add a new trusted key. As long as it's not automatically
+downloaded from the mirror without asking for any confirmation.
+
+>>   - In case we think the packages@ key may have been compromised, or is
+>>     too old, or we want to change it for any other reason, we revoke the
+>>     key, and/or revoke the signature from board@ so that it is no
+>>     longer accepted by urpmi. We create a new key, we sign it with
+>>     the board@ key and we can start to use this new key.
+> Sounds good. I'd almost suggest a new packages signing key for each new 
+> release that is valid for the supported life of the release plus one year. 
+> It's a bit more work, but would reduce the damage a key leak would cause. 
+> Unfortunately, this would bring back the problems of re-signing packages 
+> when they are turned into a release.
+
+I think we should avoid keys with expiration date because :
+ - maybe we will want to extend supported life of the release
+ - some people may want to continue using the release after end of life
+ - I don't think using expiration date reduce the damage of a leaked
+   key. If the key is leaked, we revoke it (or its signature) immediatly
+   on all key servers, which should be faster than waiting for the key to
+   expire. And replacing an expired key is not more simple than replacing
+   a revoked key.
+
+About signing each release with a different key, as they are signed from
+the same server, if a key is leaked, the others are likely to be leaked
+too, so I don't think it's very useful to use different keys.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002390.html b/zarb-ml/mageia-dev/20110131/002390.html new file mode 100644 index 000000000..71241534c --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002390.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 31 16:38:27 CET 2011 +

+
+ +
On 31 January 2011 16:03, nicolas vigier <boklm at mars-attacks.org> wrote:
+>> What if urpmi automatically trusts packages signed with a key signed by
+>> board@ and prompt on the first install of a package that is signed by a
+>> different key? The yum tool used by Fedora, RHEL, and CentOS works very
+>> well by prompting on new keys.
+>
+> For PLF packages, they will now be included on Mageia repository, so
+> most users should not need to use external repositories. However we
+> can add an option or prompt to disable this check, or an option to
+> manually add a new trusted key. As long as it's not automatically
+> downloaded from the mirror without asking for any confirmation.
+
+uh? what about patents?
+unless it's a separate repo ?
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002391.html b/zarb-ml/mageia-dev/20110131/002391.html new file mode 100644 index 000000000..196dd0a65 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002391.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 16:42:59 CET 2011 +

+
+ +
On Mon, 31 Jan 2011, Thierry Vignaud wrote:
+
+> On 31 January 2011 16:03, nicolas vigier <boklm at mars-attacks.org> wrote:
+> >> What if urpmi automatically trusts packages signed with a key signed by
+> >> board@ and prompt on the first install of a package that is signed by a
+> >> different key? The yum tool used by Fedora, RHEL, and CentOS works very
+> >> well by prompting on new keys.
+> >
+> > For PLF packages, they will now be included on Mageia repository, so
+> > most users should not need to use external repositories. However we
+> > can add an option or prompt to disable this check, or an option to
+> > manually add a new trusted key. As long as it's not automatically
+> > downloaded from the mirror without asking for any confirmation.
+> 
+> uh? what about patents?
+> unless it's a separate repo ?
+
+Yes, it's a separate repository, the tainted repository :
+http://www.mageia.org/wiki/doku.php?id=mirrors_policy
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002392.html b/zarb-ml/mageia-dev/20110131/002392.html new file mode 100644 index 000000000..81664ebf9 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002392.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Christophe Fergeau + cfergeau at gmail.com +
+ Mon Jan 31 17:08:01 CET 2011 +

+
+ +
2011/1/31 nicolas vigier <boklm at mars-attacks.org>:
+> On Sun, 30 Jan 2011, Motoko-chan wrote:
+>> What if urpmi automatically trusts packages signed with a key signed by
+>> board@ and prompt on the first install of a package that is signed by a
+>> different key? The yum tool used by Fedora, RHEL, and CentOS works very
+>> well by prompting on new keys.
+>
+> For PLF packages, they will now be included on Mageia repository, so
+> most users should not need to use external repositories. However we
+> can add an option or prompt to disable this check, or an option to
+> manually add a new trusted key. As long as it's not automatically
+> downloaded from the mirror without asking for any confirmation.
+
+You definitely want to let people set up their own local package
+repositories or to use 3rd party repositories, for example I did it
+sometimes at Mandriva for some tests, and I want to do it again for
+internal work/proprietary packages. I'm ok with having rpm/urpmi
+telling you you're about to install packages with an unknown
+signature/... as long as you can override it and tell it to let you
+install the package.
+
+Christophe
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002393.html b/zarb-ml/mageia-dev/20110131/002393.html new file mode 100644 index 000000000..731545d38 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002393.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 31 17:18:25 CET 2011 +

+
+ +
Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit :
+> On Sun, 30 Jan 2011, Motoko-chan wrote:
+>
+> > If possible, using a split key so that no single person can revoke a 
+> > signature or sign a key would be useful. This would prevent attacks where 
+> > an individual might be tricked into signing an attacker's key. It would 
+> > require multiple people to be tricked or have their systems compromised to 
+> > have that key compromised.
+> 
+> Yes, we could do something like that. Maybe each board member could have
+> a copy of the key, but encrypted with the key of all other board members,
+> so that it requires two people to access the key ? Or the people who
+> have the key don't know the passphrase, and the people who know the
+> passphrase don't have the key ?
+
+Like : http://point-at-infinity.org/ssss ?
+
+Too bad it doesn't seems to be much maintained :/
+
+
+> >>   - In case we think the packages@ key may have been compromised, or is
+> >>     too old, or we want to change it for any other reason, we revoke the
+> >>     key, and/or revoke the signature from board@ so that it is no
+> >>     longer accepted by urpmi. We create a new key, we sign it with
+> >>     the board@ key and we can start to use this new key.
+> > Sounds good. I'd almost suggest a new packages signing key for each new 
+> > release that is valid for the supported life of the release plus one year. 
+> > It's a bit more work, but would reduce the damage a key leak would cause. 
+> > Unfortunately, this would bring back the problems of re-signing packages 
+> > when they are turned into a release.
+> 
+> I think we should avoid keys with expiration date because :
+>  - maybe we will want to extend supported life of the release
+>  - some people may want to continue using the release after end of life
+
+We can 1) have a long enough expiration date ( but EOL + 1y seems quite
+enough IMHO )
+2) push unexpired keys before it is too late if needed ( I routinely
+push my key after extending the expiration date ).
+
+And people should be able to force a bypass of the system of course, but
+they will be on their own ( ie, that's quite the definition of EOL ).
+And this should be documented, and easy to do ( but warn people without
+harrassing too much can be quite difficult ).
+
+We can also say that we erase the keys once it is not planned to be used
+anymore, so we would no longer care about protecting them ( ie, we say
+the key is expired for good, and that's all ).
+
+>  - I don't think using expiration date reduce the damage of a leaked
+>    key. If the key is leaked, we revoke it (or its signature) immediatly
+>    on all key servers, which should be faster than waiting for the key to
+>    expire. And replacing an expired key is not more simple than replacing
+>    a revoked key.
+
+The problem is not leaking the key, it is about cryptographic attacks
+about older keys.
+
+If in 10 years, there is some technology that allows people to get our
+private key by bruteforce on the public one, if it is expired, attackers
+will not be able to use it even if they have it. Since the plan is to
+say "every key signed is valid", then we are potentially screwed if a
+old key is compromised offline.
+
+-- 
+Michael Scherer
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002394.html b/zarb-ml/mageia-dev/20110131/002394.html new file mode 100644 index 000000000..dfabedb87 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002394.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 17:51:11 CET 2011 +

+
+ +
On Mon, 31 Jan 2011, Michael Scherer wrote:
+
+> > So I propose that we use two keys :
+> >  - We sign all packages from all repositories using only one key. This
+> >    key is stored on the buildsystem. We can call it packages at mageia.org.
+> >  - We have an other key, that we call board at mageia.org. This key is
+> >    not used on any online server, and is supposed to never be changed,
+> >    and should not be compromised. Only a few people have a copy of this
+> >    key (some people from board ?), kept on a usb key hidden somewhere, but
+> >    not on their laptop or any computer with internet connection. This key
+> >    is used to sign the key packages at mageia.org (and revoke it if needed),
+> >    and other official keys of the project, but never used for anything
+> >    else (not for receiving encrypted messages). And the signature is
+> >    sent on public keyservers.
+> 
+> If we want to sign the key, we will have a network connection, no ?
+
+We can sign it, and copy the signed key on an other computer to upload
+it. Doing something like this :
+ - We have Computer A with internet connection.
+ - We have Computer B without internet connection, running on a livecd
+   with tmpfs
+ - On computer A: we download the packages@ public key, and the public
+   key of all board members (if needed), and save this on a USB key
+ - On computer B: we use the USB key to import all public keys in keyring
+ - On computer B: We generate the board@ key
+ - On computer B: We sign the packages@ key using board@ key
+ - On computer B: We save the signed packages@ key, and public board@
+   key on the USB key
+ - On computer A: We use the USB key to upload the signed packages@ key,
+   and board@ key on keyservers
+ - On computer B: We encrypt the board@ private key using public key of
+   board members or shamir secret sharing, and copy the encrypted files on
+   USB keys to give them to board members
+ - We destroy computer B (or alternatively we simply turn it off to
+   remove tmpfs)
+
+> > If we decide to do this, someone from board could generate the key next
+> > week at fosdem after the election, save it on usb key for other board
+> > members, and give the fingerprint to everybody to sign the key.
+> 
+> I would rather make sure that the key cannot be used by only one board
+> member. Not that I do not trust people for that ( they are the board
+> after all ), but it would be safer to have it distributed and resilient
+> if someone steal the key ( like a burglar, etc ). 
+> 
+> Maybe have it password protected should be sufficient ( except if people
+> forget that password, or stick it to the key ). 
+> 
+> Pascal proposed to use https://store.ironkey.com/personal , on the
+> thread
+> https://www.mageia.org/pipermail/mageia-sysadm/2011-January/002155.html
+> 
+> Another last solution to prevent theft would to use shamir secret
+> sharing ( as also said in the other thread, but maybe I am too insistant
+> on this wonderful cryptographic invention ). This way, people would have
+> to steal several part of the file to get something usable.
+> ( for Harry Potter fan, think of horcruxes )
+
+Oops, I should have mentioned this thread in the 1st mail (but didn't
+find it yesterday).
+
+> And also, I think we should routinely make sure the key is readable
+> ( ie, that people know where it is, and the support is still good ), so
+> we do not discover one day that half the key keeper lost the key while
+> moving, thinking someone else had it, and the other half stored it near
+> magnet, rendering it unreadable.
+
+Maybe we could test it every year at fosdem ?
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002395.html b/zarb-ml/mageia-dev/20110131/002395.html new file mode 100644 index 000000000..386ec11f5 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002395.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 18:01:16 CET 2011 +

+
+ +
On Mon, 31 Jan 2011, Christophe Fergeau wrote:
+
+> 2011/1/31 nicolas vigier <boklm at mars-attacks.org>:
+> > On Sun, 30 Jan 2011, Motoko-chan wrote:
+> >> What if urpmi automatically trusts packages signed with a key signed by
+> >> board@ and prompt on the first install of a package that is signed by a
+> >> different key? The yum tool used by Fedora, RHEL, and CentOS works very
+> >> well by prompting on new keys.
+> >
+> > For PLF packages, they will now be included on Mageia repository, so
+> > most users should not need to use external repositories. However we
+> > can add an option or prompt to disable this check, or an option to
+> > manually add a new trusted key. As long as it's not automatically
+> > downloaded from the mirror without asking for any confirmation.
+> 
+> You definitely want to let people set up their own local package
+> repositories or to use 3rd party repositories, for example I did it
+> sometimes at Mandriva for some tests, and I want to do it again for
+> internal work/proprietary packages. I'm ok with having rpm/urpmi
+> telling you you're about to install packages with an unknown
+> signature/... as long as you can override it and tell it to let you
+> install the package.
+
+Yes, we should add an option somewhere to allow this.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002396.html b/zarb-ml/mageia-dev/20110131/002396.html new file mode 100644 index 000000000..ae412c9f7 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002396.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 18:26:46 CET 2011 +

+
+ +
On Mon, 31 Jan 2011, Michael Scherer wrote:
+
+> Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit :
+> > On Sun, 30 Jan 2011, Motoko-chan wrote:
+> >
+> > > If possible, using a split key so that no single person can revoke a 
+> > > signature or sign a key would be useful. This would prevent attacks where 
+> > > an individual might be tricked into signing an attacker's key. It would 
+> > > require multiple people to be tricked or have their systems compromised to 
+> > > have that key compromised.
+> > 
+> > Yes, we could do something like that. Maybe each board member could have
+> > a copy of the key, but encrypted with the key of all other board members,
+> > so that it requires two people to access the key ? Or the people who
+> > have the key don't know the passphrase, and the people who know the
+> > passphrase don't have the key ?
+> 
+> Like : http://point-at-infinity.org/ssss ?
+> 
+> Too bad it doesn't seems to be much maintained :/
+
+Interesting.
+
+> > >>   - In case we think the packages@ key may have been compromised, or is
+> > >>     too old, or we want to change it for any other reason, we revoke the
+> > >>     key, and/or revoke the signature from board@ so that it is no
+> > >>     longer accepted by urpmi. We create a new key, we sign it with
+> > >>     the board@ key and we can start to use this new key.
+> > > Sounds good. I'd almost suggest a new packages signing key for each new 
+> > > release that is valid for the supported life of the release plus one year. 
+> > > It's a bit more work, but would reduce the damage a key leak would cause. 
+> > > Unfortunately, this would bring back the problems of re-signing packages 
+> > > when they are turned into a release.
+> > 
+> > I think we should avoid keys with expiration date because :
+> >  - maybe we will want to extend supported life of the release
+> >  - some people may want to continue using the release after end of life
+> 
+> We can 1) have a long enough expiration date ( but EOL + 1y seems quite
+> enough IMHO )
+> 2) push unexpired keys before it is too late if needed ( I routinely
+> push my key after extending the expiration date ).
+
+Pushing new unexpired keys also means we need to resign all old packages
+if we want them to be installable. So that's not something we want to do
+too often if it's not needed.
+
+> And people should be able to force a bypass of the system of course, but
+> they will be on their own ( ie, that's quite the definition of EOL ).
+> And this should be documented, and easy to do ( but warn people without
+> harrassing too much can be quite difficult ).
+> 
+> We can also say that we erase the keys once it is not planned to be used
+> anymore, so we would no longer care about protecting them ( ie, we say
+> the key is expired for good, and that's all ).
+
+If we decide that a key won't be used anymore, and don't want to care
+about protecting it, I think we should revoke it (or its signature) as
+soon as possible, instead of waiting for it to expire.
+
+I think the only use of expiration date would be if one day all
+known keyservers are down and never come back (I think it's unlikely to
+happen, or we will also have other problems), or we lose all private
+keys, so we can't revoke them or their signature. But if we lose all
+private keys, we will also have other problems (like not being able to
+sign a new key), so we should avoid it.
+
+> >  - I don't think using expiration date reduce the damage of a leaked
+> >    key. If the key is leaked, we revoke it (or its signature) immediatly
+> >    on all key servers, which should be faster than waiting for the key to
+> >    expire. And replacing an expired key is not more simple than replacing
+> >    a revoked key.
+> 
+> The problem is not leaking the key, it is about cryptographic attacks
+> about older keys.
+> 
+> If in 10 years, there is some technology that allows people to get our
+> private key by bruteforce on the public one, if it is expired, attackers
+> will not be able to use it even if they have it. Since the plan is to
+> say "every key signed is valid", then we are potentially screwed if a
+> old key is compromised offline.
+
+If in 10 years there is some technology to get our private key, then
+it's still possible to revoke the key at that time. Instead of deciding
+now that the key will expire in a few years, I would prefer that we look
+at it in a few years to decide if we want to revoke it.
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002397.html b/zarb-ml/mageia-dev/20110131/002397.html new file mode 100644 index 000000000..306031dfc --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002397.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 31 18:56:27 CET 2011 +

+
+ +
Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
+> On Mon, 31 Jan 2011, Michael Scherer wrote:
+> 
+> > Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit :
+> > > On Sun, 30 Jan 2011, Motoko-chan wrote:
+
+> > > >>   - In case we think the packages@ key may have been compromised, or is
+> > > >>     too old, or we want to change it for any other reason, we revoke the
+> > > >>     key, and/or revoke the signature from board@ so that it is no
+> > > >>     longer accepted by urpmi. We create a new key, we sign it with
+> > > >>     the board@ key and we can start to use this new key.
+> > > > Sounds good. I'd almost suggest a new packages signing key for each new 
+> > > > release that is valid for the supported life of the release plus one year. 
+> > > > It's a bit more work, but would reduce the damage a key leak would cause. 
+> > > > Unfortunately, this would bring back the problems of re-signing packages 
+> > > > when they are turned into a release.
+> > > 
+> > > I think we should avoid keys with expiration date because :
+> > >  - maybe we will want to extend supported life of the release
+> > >  - some people may want to continue using the release after end of life
+> > 
+> > We can 1) have a long enough expiration date ( but EOL + 1y seems quite
+> > enough IMHO )
+> > 2) push unexpired keys before it is too late if needed ( I routinely
+> > push my key after extending the expiration date ).
+> 
+> Pushing new unexpired keys also means we need to resign all old packages
+> if we want them to be installable. So that's not something we want to do
+> too often if it's not needed.
+
+Nope, I didn't say "new unexpired key", but just push the same key, with
+the expiration date extended. That should be painless IIRC ( at least,
+it is for me ).
+ 
+> > And people should be able to force a bypass of the system of course, but
+> > they will be on their own ( ie, that's quite the definition of EOL ).
+> > And this should be documented, and easy to do ( but warn people without
+> > harrassing too much can be quite difficult ).
+> > 
+> > We can also say that we erase the keys once it is not planned to be used
+> > anymore, so we would no longer care about protecting them ( ie, we say
+> > the key is expired for good, and that's all ).
+> 
+> If we decide that a key won't be used anymore, and don't want to care
+> about protecting it, I think we should revoke it (or its signature) as
+> soon as possible, instead of waiting for it to expire.
+
+Well, we can do both. Revoke it, and for those that still use it and
+didn't update, let it expires.
+
+> I think the only use of expiration date would be if one day all
+> known keyservers are down and never come back (I think it's unlikely to
+> happen, or we will also have other problems)
+
+Yep, unlikely ( unless in Egypt )
+
+Maybe this also mean we should have a SKS server too
+( http://minskyprimus.net/sks/ ).
+
+> , or we lose all private
+> keys, so we can't revoke them or their signature. But if we lose all
+> private keys, we will also have other problems (like not being able to
+> sign a new key), so we should avoid it.
+
+Usually, revokation certificates can be prepared in advance. ( in case
+you lose the key, simply ). So this should also be done.
+
+The point about losing all keys also mean we need to take backup in
+accounts ( for example, encrypt them, bacula can do it client side ).
+ 
+> > >  - I don't think using expiration date reduce the damage of a leaked
+> > >    key. If the key is leaked, we revoke it (or its signature) immediatly
+> > >    on all key servers, which should be faster than waiting for the key to
+> > >    expire. And replacing an expired key is not more simple than replacing
+> > >    a revoked key.
+> > 
+> > The problem is not leaking the key, it is about cryptographic attacks
+> > about older keys.
+> > 
+> > If in 10 years, there is some technology that allows people to get our
+> > private key by bruteforce on the public one, if it is expired, attackers
+> > will not be able to use it even if they have it. Since the plan is to
+> > say "every key signed is valid", then we are potentially screwed if a
+> > old key is compromised offline.
+> 
+> If in 10 years there is some technology to get our private key, then
+> it's still possible to revoke the key at that time. 
+>
+> Instead of deciding
+> now that the key will expire in a few years, I would prefer that we look
+> at it in a few years to decide if we want to revoke it.
+
+Wouldn't it be too late ?
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002398.html b/zarb-ml/mageia-dev/20110131/002398.html new file mode 100644 index 000000000..53bc05c7b --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002398.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Jan 31 20:12:24 CET 2011 +

+
+ +
On Mon, 31 Jan 2011, Michael Scherer wrote:
+
+> Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
+> > On Mon, 31 Jan 2011, Michael Scherer wrote:
+> > 
+> > > We can 1) have a long enough expiration date ( but EOL + 1y seems quite
+> > > enough IMHO )
+> > > 2) push unexpired keys before it is too late if needed ( I routinely
+> > > push my key after extending the expiration date ).
+> > 
+> > Pushing new unexpired keys also means we need to resign all old packages
+> > if we want them to be installable. So that's not something we want to do
+> > too often if it's not needed.
+> 
+> Nope, I didn't say "new unexpired key", but just push the same key, with
+> the expiration date extended. That should be painless IIRC ( at least,
+> it is for me ).
+
+Oh, I misunderstood this as I imagined it was not possible to change
+expiration date on a key as it would be difficult to check if the change
+was done before expiration. But after checking, it is indeed possible,
+and it is even possible to do it after the expiration date.
+
+So we can do it, but we should remember that it does not protect against
+a key compromised after it has expired (as someone stealing the key
+can change the expiration date even after it has expired).
+
+So the only use of expiration date I see is to check that the key was
+updated from keyserver recently. Maybe we can set a short expiration
+time (15 days ?), and have something in cron to update it a few days
+before it expire ?
+
+> > > >  - I don't think using expiration date reduce the damage of a leaked
+> > > >    key. If the key is leaked, we revoke it (or its signature) immediatly
+> > > >    on all key servers, which should be faster than waiting for the key to
+> > > >    expire. And replacing an expired key is not more simple than replacing
+> > > >    a revoked key.
+> > > 
+> > > The problem is not leaking the key, it is about cryptographic attacks
+> > > about older keys.
+> > > 
+> > > If in 10 years, there is some technology that allows people to get our
+> > > private key by bruteforce on the public one, if it is expired, attackers
+> > > will not be able to use it even if they have it. Since the plan is to
+> > > say "every key signed is valid", then we are potentially screwed if a
+> > > old key is compromised offline.
+> > 
+> > If in 10 years there is some technology to get our private key, then
+> > it's still possible to revoke the key at that time. 
+> >
+> > Instead of deciding
+> > now that the key will expire in a few years, I would prefer that we look
+> > at it in a few years to decide if we want to revoke it.
+> 
+> Wouldn't it be too late ?
+
+Considering that it is possible to update expiration date even after it
+has expired, this expiration date doesn't protect against some technology
+that would allow people in the futur to bruteforce the private key.
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ 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 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Michael Scherer + misc at zarb.org +
+ Mon Jan 31 20:37:07 CET 2011 +

+
+ +
Le lundi 31 janvier 2011 à 20:12 +0100, nicolas vigier a écrit :
+> On Mon, 31 Jan 2011, Michael Scherer wrote:
+>
+> > Nope, I didn't say "new unexpired key", but just push the same key, with
+> > the expiration date extended. That should be painless IIRC ( at least,
+> > it is for me ).
+> 
+> Oh, I misunderstood this as I imagined it was not possible to change
+> expiration date on a key as it would be difficult to check if the change
+> was done before expiration. But after checking, it is indeed possible,
+> and it is even possible to do it after the expiration date.
+> 
+> So we can do it, but we should remember that it does not protect against
+> a key compromised after it has expired (as someone stealing the key
+> can change the expiration date even after it has expired).
+
+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 :)
+
+> So the only use of expiration date I see is to check that the key was
+> updated from keyserver recently. Maybe we can set a short expiration
+> time (15 days ?), and have something in cron to update it a few days
+> before it expire ?
+
+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 ).
+
+> > > Instead of deciding
+> > > now that the key will expire in a few years, I would prefer that we look
+> > > at it in a few years to decide if we want to revoke it.
+> > 
+> > Wouldn't it be too late ?
+> 
+> Considering that it is possible to update expiration date even after it
+> has expired, this expiration date doesn't protect against some technology
+> that would allow people in the futur to bruteforce the private key.
+
+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
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002400.html b/zarb-ml/mageia-dev/20110131/002400.html new file mode 100644 index 000000000..c1522b441 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002400.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jan 31 20:40:00 CET 2011 +

+
+ +
Op maandag 31 januari 2011 18:01:16 schreef nicolas vigier:
+> On Mon, 31 Jan 2011, Christophe Fergeau wrote:
+> > 2011/1/31 nicolas vigier <boklm at mars-attacks.org>:
+> > > On Sun, 30 Jan 2011, Motoko-chan wrote:
+> > >> What if urpmi automatically trusts packages signed with a key signed
+> > >> by board@ and prompt on the first install of a package that is signed
+> > >> by a different key? The yum tool used by Fedora, RHEL, and CentOS
+> > >> works very well by prompting on new keys.
+> > > 
+> > > For PLF packages, they will now be included on Mageia repository, so
+> > > most users should not need to use external repositories. However we
+> > > can add an option or prompt to disable this check, or an option to
+> > > manually add a new trusted key. As long as it's not automatically
+> > > downloaded from the mirror without asking for any confirmation.
+> > 
+> > You definitely want to let people set up their own local package
+> > repositories or to use 3rd party repositories, for example I did it
+> > sometimes at Mandriva for some tests, and I want to do it again for
+> > internal work/proprietary packages. I'm ok with having rpm/urpmi
+> > telling you you're about to install packages with an unknown
+> > signature/... as long as you can override it and tell it to let you
+> > install the package.
+> 
+> Yes, we should add an option somewhere to allow this.
+
+isn't it easier if local overrides would also provide a way to add keys that 
+can be validated, imo.
+
+I'm writing urpmi-proxy, and and i would like to have a good way to have local 
+overrides with their own key signed.
+
+perhaps if a diff key is detected, a certain procedure could be started that 
+could ask the user if this key is trusted or not, or refer to somewhere else?
+
+also, thinking on the upgrade path from Mandriva, i'm not sure how...
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ 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 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Jan 31 20:42:44 CET 2011 +

+
+ +
Op maandag 31 januari 2011 20:12:24 schreef nicolas vigier:
+> On Mon, 31 Jan 2011, Michael Scherer wrote:
+> > Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
+> > > On Mon, 31 Jan 2011, Michael Scherer wrote:
+> > > > We can 1) have a long enough expiration date ( but EOL + 1y seems
+> > > > quite enough IMHO )
+> > > > 2) push unexpired keys before it is too late if needed ( I routinely
+> > > > push my key after extending the expiration date ).
+> > > 
+> > > Pushing new unexpired keys also means we need to resign all old
+> > > packages if we want them to be installable. So that's not something we
+> > > want to do too often if it's not needed.
+> > 
+> > Nope, I didn't say "new unexpired key", but just push the same key, with
+> > the expiration date extended. That should be painless IIRC ( at least,
+> > it is for me ).
+> 
+> Oh, I misunderstood this as I imagined it was not possible to change
+> expiration date on a key as it would be difficult to check if the change
+> was done before expiration. But after checking, it is indeed possible,
+> and it is even possible to do it after the expiration date.
+> 
+> So we can do it, but we should remember that it does not protect against
+> a key compromised after it has expired (as someone stealing the key
+> can change the expiration date even after it has expired).
+> 
+> So the only use of expiration date I see is to check that the key was
+> updated from keyserver recently. Maybe we can set a short expiration
+> time (15 days ?), and have something in cron to update it a few days
+> before it expire ?
+> 
+> > > > >  - I don't think using expiration date reduce the damage of a
+> > > > >  leaked
+> > > > >  
+> > > > >    key. If the key is leaked, we revoke it (or its signature)
+> > > > >    immediatly on all key servers, which should be faster than
+> > > > >    waiting for the key to expire. And replacing an expired key is
+> > > > >    not more simple than replacing a revoked key.
+> > > > 
+> > > > The problem is not leaking the key, it is about cryptographic attacks
+> > > > about older keys.
+> > > > 
+> > > > If in 10 years, there is some technology that allows people to get
+> > > > our private key by bruteforce on the public one, if it is expired,
+> > > > attackers will not be able to use it even if they have it. Since the
+> > > > plan is to say "every key signed is valid", then we are potentially
+> > > > screwed if a old key is compromised offline.
+> > > 
+> > > If in 10 years there is some technology to get our private key, then
+> > > it's still possible to revoke the key at that time.
+> > > 
+> > > Instead of deciding
+> > > now that the key will expire in a few years, I would prefer that we
+> > > look at it in a few years to decide if we want to revoke it.
+> > 
+> > Wouldn't it be too late ?
+> 
+> Considering that it is possible to update expiration date even after it
+> has expired, this expiration date doesn't protect against some technology
+> that would allow people in the futur to bruteforce the private key.
+
+
+what if there is no network access? keyservers are nice, but an isolated 
+install should still be possible...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002402.html b/zarb-ml/mageia-dev/20110131/002402.html new file mode 100644 index 000000000..0186fbf95 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002402.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Mon Jan 31 21:41:34 CET 2011 +

+
+ +
On Mon, 31 Jan 2011 14:12:24 -0500, nicolas vigier <boklm at mars-attacks.org> wrote:
+
+> So the only use of expiration date I see is to check that the key was
+> updated from keyserver recently. Maybe we can set a short expiration
+> time (15 days ?), and have something in cron to update it a few days
+> before it expire ?
+
+What about systems that are not connected to the internet?  I see no
+point in having the key expire.  If a person chooses to install an
+old version after the release has reached end of life, that is their
+choice.  They shouldn't have to jump through hoops, just to get the
+installer to run.
+
+If a key gets compromised, it gets revoked, and the revocation certificate
+gets distributed as an update, along with a new key.
+
+Regards, Dave Hodgins
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002403.html b/zarb-ml/mageia-dev/20110131/002403.html new file mode 100644 index 000000000..52ac98432 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002403.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] PGP keys and package signing + + + + + + + + + +

[Mageia-dev] PGP keys and package signing

+ Dick Gevers + dvgevers at xs4all.nl +
+ Mon Jan 31 22:49:32 CET 2011 +

+
+ +
On Mon, 31 Jan 2011 17:18:25 +0100, Michael Scherer wrote about Re:
+[Mageia-dev] PGP keys and package signing:
+
+>The problem is not leaking the key, it is about cryptographic attacks
+>about older keys.
+>
+>If in 10 years, there is some technology that allows people to get our
+>private key by bruteforce on the public one
+
+You can never ever obtain the private key from the public one, that is
+impossible. It can only be compromised if someone looses the private key
+plus the password is cracked.
+
+Cheers.
+=Dick Gevers=
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002404.html b/zarb-ml/mageia-dev/20110131/002404.html new file mode 100644 index 000000000..1b6b971fc --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002404.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] please release mgarepo-1.9.8 + + + + + + + + + +

[Mageia-dev] please release mgarepo-1.9.8

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Jan 31 23:48:30 CET 2011 +

+
+ +
Hi
+
+Please fix your upload process since:
+-  mgarepo-1.9.8 (which has fixed sync option) is half-released
+  (aka the SRPM is in http://repository.mageia.org/mageiatools/SRPMS/
+   but binary packages are still 1.9.7)
+- also since you're using setup.py instead of plain old Makefile, we're missing
+   the release bits in order to do a tarball
+   it would be nice if this could be documented
+   (even "VERSION=$(egrep '^VERSION' mgarepo|cut -f 2 -d=|sed -e
+'s!"!!g'); cd ..;ln -s mgarepo mgarepo-$VERSION; tar cfz
+mgarepo-$VERSION{.tgz,/}")
+  but please documente it.
+
+thanks.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/002422.html b/zarb-ml/mageia-dev/20110131/002422.html new file mode 100644 index 000000000..ae2452ef4 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002422.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Dev Team Call To Action... + + + + + + + + + +

[Mageia-dev] Dev Team Call To Action...

+ Nex6 + borg at borg1911.com +
+ Mon Jan 31 20:53:14 CET 2011 +

+
+ +
I am interested in the dev team still
+
+
+On 1/26/2011 4:59 PM, Maarten Vanraes wrote:
+> Hi,
+>
+> I sent email on mageia-dev regarding the -dev team and "a call for action":
+> http://www.mageia.org/pipermail/mageia-dev/20110127/002345.html
+>
+> Are you still interested in -dev team or like to contribute for this
+> particular thing, could you react to the email in question?
+>
+> Regards,
+>
+> Maarten (aka AL13N)
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110131/author.html b/zarb-ml/mageia-dev/20110131/author.html new file mode 100644 index 000000000..2fc58e6f4 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/author.html @@ -0,0 +1,177 @@ + + + + The Mageia-dev 31 January 2011 Archive by author + + + + + +

31 January 2011 Archives by author

+ +

Starting: Mon Jan 31 04:16:43 CET 2011
+ Ending: Mon Jan 31 23:48:30 CET 2011
+ Messages: 26

+

+

+ Last message date: + Mon Jan 31 23:48:30 CET 2011
+ Archived on: Thu Feb 3 17:48:11 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110131/date.html b/zarb-ml/mageia-dev/20110131/date.html new file mode 100644 index 000000000..ab8d70e49 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/date.html @@ -0,0 +1,177 @@ + + + + The Mageia-dev 31 January 2011 Archive by date + + + + + +

31 January 2011 Archives by date

+ +

Starting: Mon Jan 31 04:16:43 CET 2011
+ Ending: Mon Jan 31 23:48:30 CET 2011
+ Messages: 26

+

+

+ Last message date: + Mon Jan 31 23:48:30 CET 2011
+ Archived on: Thu Feb 3 17:48:11 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110131/index.html b/zarb-ml/mageia-dev/20110131/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/20110131/subject.html b/zarb-ml/mageia-dev/20110131/subject.html new file mode 100644 index 000000000..9e384575f --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/subject.html @@ -0,0 +1,177 @@ + + + + The Mageia-dev 31 January 2011 Archive by subject + + + + + +

31 January 2011 Archives by subject

+ +

Starting: Mon Jan 31 04:16:43 CET 2011
+ Ending: Mon Jan 31 23:48:30 CET 2011
+ Messages: 26

+

+

+ Last message date: + Mon Jan 31 23:48:30 CET 2011
+ Archived on: Thu Feb 3 17:48:11 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110131/thread.html b/zarb-ml/mageia-dev/20110131/thread.html new file mode 100644 index 000000000..7c23474f6 --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/thread.html @@ -0,0 +1,215 @@ + + + + The Mageia-dev 31 January 2011 Archive by thread + + + + + +

31 January 2011 Archives by thread

+ +

Starting: Mon Jan 31 04:16:43 CET 2011
+ Ending: Mon Jan 31 23:48:30 CET 2011
+ Messages: 26

+

+

+ Last message date: + Mon Jan 31 23:48:30 CET 2011
+ Archived on: Thu Feb 3 17:48:11 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1