[gentoo-dev] [PATCH v4 07/14] glep-0063: Change the recommended RSA key size to 2048 bits
Change the recommended key size recommendation for RSA from 4096 bits to 2048 bits. Use of larger keys is unjustified due to negligible gain in security, and recommending RSA-4096 unnecessarily resulted in developers replacing their RSA-2048 keys for no good reason. --- glep-0063.rst | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index a93e6ac..b2e6679 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -7,7 +7,7 @@ Author: Robin H. Johnson , Michał Górny Type: Standards Track Status: Final -Version: 1 +Version: 1.1 Created: 2013-02-18 Last-Modified: 2018-07-07 Post-History: 2013-11-10 @@ -25,6 +25,15 @@ Abstract This GLEP provides both a minimum requirement and a recommended set of OpenPGP key management policies for the Gentoo Linux distribution. +Changes +=== + +v1.1 + The recommended RSA key size has been changed from 4096 bits + to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. + The larger recommendation was unjustified and resulted in people + unnecessarily replacing their RSA-2048 keys. + Motivation == @@ -113,15 +122,13 @@ their primary key). # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 -2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later) - - This may require creating an entirely new key. +2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later) 3. The signing subkey of EITHER: a. DSA 2048 bits exactly. - b. RSA 4096 bits exactly. + b. RSA 2048 bits exactly. 4. Key expiry: @@ -174,6 +181,9 @@ Much of the above was driven by the following: References == +.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096? + (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096) + .. [#DEBIANGPG] Debian GPG documentation (https://wiki.debian.org/Keysigning) -- 2.18.0
[gentoo-dev] [PATCH v4 05/14] glep-0063: Split out the signing subkey into a separate point
Reword the specification to express the requirement for separate signing subkey more verbosely. Replace the ambiguous term 'dedicated' with clear explanation that it needs to be different from the primary key and not used for other purposes. Suggested-by: Kristian Fiskerstrand --- glep-0063.rst | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 940612c..05e5e9d 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -46,15 +46,18 @@ Bare minimum requirements personal-digest-preferences SHA256 -2. Primary key and signing subkey of EITHER: +2. Signing subkey that is different from the primary key, and does not + have any other capabilities enabled. + +3. Primary key and the signing subkey are both of type EITHER: a. DSA, 2048-bit b. RSA, >=2048 bits (OpenPGP v4 key format or later only) -3. Key expiry: 5 years maximum +4. Key expiry: 5 years maximum -4. Upload your key to the SKS keyserver rotation before usage! +5. Upload your key to the SKS keyserver rotation before usage! Recommendations --- @@ -106,7 +109,7 @@ Recommendations This may require creating an entirely new key. -3. Dedicated signing subkey of EITHER: +3. The signing subkey of EITHER: a. DSA 2048 bits exactly. -- 2.18.0
[gentoo-dev] [PATCH v4 06/14] glep-0063: Explain minimal & recommended sections
--- glep-0063.rst | 8 1 file changed, 8 insertions(+) diff --git a/glep-0063.rst b/glep-0063.rst index 05e5e9d..a93e6ac 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -41,6 +41,10 @@ Specifications for OpenPGP keys Bare minimum requirements - +This section specifies obligatory requirements for all OpenPGP keys used +to commit to Gentoo. Keys that do not conform to those requirements can +not be used to commit. + 1. SHA2-series output digest (SHA1 digests internally permitted), 256bit or more:: @@ -61,6 +65,10 @@ Bare minimum requirements Recommendations --- +This section specifies the best practices for Gentoo developers. +The developers should follow those practices unless there is a strong +technical reason not to (e.g. hardware limitations, necessity of replacing +their primary key). 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append the following block:: -- 2.18.0
[gentoo-dev] [PATCH v4 03/14] glep-0063: 'Gentoo subkey' → 'Signing subkey'
Replace the 'Gentoo subkey' term that might wrongly suggest that the developers are expected to create an additional, dedicated subkey for Gentoo. Suggested-by: Kristian Fiskerstrand --- glep-0063.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glep-0063.rst b/glep-0063.rst index 7af8d09..6be2555 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -116,7 +116,7 @@ Recommendations a. Root key: 3 years maximum, expiry date renewed annually. - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. + b. Signing subkey: 1 year maximum, expiry date renewed every 6 months. 5. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -- 2.18.0
[gentoo-dev] [PATCH v4 04/14] glep-0063: Root key → primary key
Replace the custom term 'root key' with much more common 'primary key'. This is also the term used in GnuPG output. --- glep-0063.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 6be2555..940612c 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -46,7 +46,7 @@ Bare minimum requirements personal-digest-preferences SHA256 -2. Root key and signing subkey of EITHER: +2. Primary key and signing subkey of EITHER: a. DSA, 2048-bit @@ -102,7 +102,7 @@ Recommendations # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 -2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later) +2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later) This may require creating an entirely new key. @@ -114,7 +114,7 @@ Recommendations 4. Key expiry: - a. Root key: 3 years maximum, expiry date renewed annually. + a. Primary key: 3 years maximum, expiry date renewed annually. b. Signing subkey: 1 year maximum, expiry date renewed every 6 months. @@ -126,7 +126,7 @@ Recommendations Gentoo LDAP === -All Gentoo developers must list the complete fingerprint for their root +All Gentoo developers must list the complete fingerprint for their primary keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, uppercase, with optional spaces every 8 hex digits. Regular expression for validation:: -- 2.18.0
[gentoo-dev] [PATCH v4 02/14] glep-0063: RSAv4 -> OpenPGP v4 key format
Replace the 'RSAv4' with 'OpenPGP v4 key format'. The RSA algorithm does not really have versions, and the author most likely meant the v4 of OpenPGP key format as outlined in RFC 4880, section 12.1. This was figured out and explained to me by Kristian Fiskerstrand. --- glep-0063.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 522a3fd..7af8d09 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -50,7 +50,7 @@ Bare minimum requirements a. DSA, 2048-bit - b. RSA, >=2048 bits, RSAv4 or later only + b. RSA, >=2048 bits (OpenPGP v4 key format or later only) 3. Key expiry: 5 years maximum @@ -102,7 +102,7 @@ Recommendations # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 -2. Root key type RSA, 4096 bits, RSAv4 or later +2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later) This may require creating an entirely new key. -- 2.18.0
[gentoo-dev] [PATCH v4 01/14] glep-0063: Use 'OpenPGP' as appropriate
Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP. G[nu]PG has been left where the text clearly refers to the specific implementation of OpenPGP rather than the standard itself. --- glep-0063.rst | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index c59d545..522a3fd 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -1,14 +1,15 @@ --- GLEP: 63 -Title: Gentoo GPG key policies +Title: Gentoo OpenPGP policies Author: Robin H. Johnson , Andreas K. Hüttel , -Marissa Fischer +Marissa Fischer , +Michał Górny Type: Standards Track Status: Final Version: 1 Created: 2013-02-18 -Last-Modified: 2015-08-25 +Last-Modified: 2018-07-07 Post-History: 2013-11-10 Content-Type: text/x-rst --- @@ -21,22 +22,22 @@ Many developers and external sources helped in this GLEP. Abstract -This GLEP provides both a minimum requirement and a recommended set of GPG -key management policies for the Gentoo Linux distribution. +This GLEP provides both a minimum requirement and a recommended set of +OpenPGP key management policies for the Gentoo Linux distribution. Motivation == Given the increasing use and importance of cryptographic protocols in internet -transactions of any kind, unified requirements for GnuPG keys used in Gentoo +transactions of any kind, unified requirements for OpenPGP keys used in Gentoo Linux development are sorely needed. This document provides both a set of bare minimum requirements and a set of best practice recommendations for -the use of GnuPG by Gentoo Linux developers. It is intended to provide -a basis for future improvements such as, e.g., consistent ebuild or package -signing and verifying by end users. +the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. +It is intended to provide a basis for future improvements such as, e.g., +consistent ebuild or package signing and verifying by end users. -Specifications for GnuPG keys -= +Specifications for OpenPGP keys +=== Bare minimum requirements - @@ -125,7 +126,7 @@ Recommendations Gentoo LDAP === -All Gentoo developers must list the complete GPG fingerprint for their root +All Gentoo developers must list the complete fingerprint for their root keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, uppercase, with optional spaces every 8 hex digits. Regular expression for validation:: @@ -195,7 +196,8 @@ References Copyright = -Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer. +Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer, +Michał Górny. This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit -- 2.18.0
[gentoo-dev] [PATCH v4 00/14] GLEP 63 update
Hi, Here's the next iteration of the GLEP, integrating even more suggestions from developers. Full text below. Also, please do not reply to previous versions, as this is making the discussion really hard to follow. -- Best regards, Michał Górny Michał Górny (14): glep-0063: Use 'OpenPGP' as appropriate glep-0063: RSAv4 -> OpenPGP v4 key format glep-0063: 'Gentoo subkey' → 'Signing subkey' glep-0063: Root key → primary key glep-0063: Split out the signing subkey into a separate point glep-0063: Explain minimal & recommended sections glep-0063: Change the recommended RSA key size to 2048 bits glep-0063: Allow ECC curve 25519 keys glep-0063: Stop recommending DSA subkeys glep-0063: Update and unify expiration term glep-0063: Require renewal 2 weeks before expiration glep-0063: Disallow using DSA keys glep-0063: Remove whitespace from LDAP field glep-0063: Remove recommended gpg.conf glep-0063.rst | 158 -- 1 file changed, 76 insertions(+), 82 deletions(-) -- 2.18.0 --- GLEP: 63 Title: Gentoo OpenPGP policies Author: Robin H. Johnson , Andreas K. Hüttel , Marissa Fischer , Michał Górny Type: Standards Track Status: Final Version: 2 Created: 2013-02-18 Last-Modified: 2018-07-07 Post-History: 2013-11-10 Content-Type: text/x-rst --- Credits === Many developers and external sources helped in this GLEP. Abstract This GLEP provides both a minimum requirement and a recommended set of OpenPGP key management policies for the Gentoo Linux distribution. Changes === v2 The distinct minimal and recommended expirations have been replaced by a single requirement. The rules have been simplified to use the same maximum time of 900 days for both the primary key and subkeys. An additional rule requesting key renewal 2 weeks before expiration has been added. This is in order to give services and other developers time to refresh the key. The usage of DSA keys has been disallowed. The ``gpgfingerprint`` LDAP field has been altered to remove optional whitespace. The recommended ``gpg.conf`` contents have been removed as they were seriously outdated and decreased security over the modern defaults. v1.1 The recommended RSA key size has been changed from 4096 bits to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. The larger recommendation was unjustified and resulted in people unnecessarily replacing their RSA-2048 keys. Minimal specification has been amended to allow for ECC keys. The option of using DSA subkey has been removed from recommendations. The section now specifies a single recommendation of using RSA. Motivation == Given the increasing use and importance of cryptographic protocols in internet transactions of any kind, unified requirements for OpenPGP keys used in Gentoo Linux development are sorely needed. This document provides both a set of bare minimum requirements and a set of best practice recommendations for the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. It is intended to provide a basis for future improvements such as, e.g., consistent ebuild or package signing and verifying by end users. Specifications for OpenPGP keys === Bare minimum requirements - This section specifies obligatory requirements for all OpenPGP keys used to commit to Gentoo. Keys that do not conform to those requirements can not be used to commit. 1. SHA2-series output digest (SHA1 digests internally permitted), 256bit or more:: personal-digest-preferences SHA256 2. Signing subkey that is different from the primary key, and does not have any other capabilities enabled. 3. Primary key and the signing subkey are both of type EITHER: a. RSA, >=2048 bits (OpenPGP v4 key format or later only) b. ECC curve 25519 4. Expiration date on key and all subkeys set to no more than 900 days into the future 5. Key expiration date renewed at least 2 weeks before the previous expiration date. 6. Upload your key to the SKS keyserver rotation before usage! Recommendations --- This section specifies the best practices for Gentoo developers. The developers should follow those practices unless there is a strong technical reason not to (e.g. hardware limitations, necessity of replacing their primary key). 1. Primary key and the signing subkey are both of type RSA, 2048 bits (OpenPGP v4 key format or later) 2. Key expiration renewed annually to a fixed day of the year 3. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). 4. Encrypted backup of your secret keys. Gentoo LDAP === All Gentoo developers must list the complete fingerprint for their primary keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, uppercase, without whitespace. The prior "``gpgkey``"
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the required schedule.
>
> So effectively we're down from 5 years to 1 year also for the main
> key, as a mandatory requirement? That is not what I have perceived
> as the consensus in the discussion so far.
>
> > I really see no point in added complexity just so that someone could
> > bend the standard to the limits.
>
> It isn't complicated in the current version of GLEP 63 ("5 years
> maximum"). Simply keep that wording, or moderately shorten it, to
> something like 3 years, or 2.25 years. (Or if you prefer round
> numbers, 800 days, or 7000 seconds.) :-)
>
Went for 900 days. This will be easier to test script-wise
(i.e. without having to fight over how many days a year has)
and give you a long grace period for early renewal (and for keys created
late in the year).
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 00/12] GLEP 63 update
W dniu pią, 06.07.2018 o godzinie 21∶26 -0400, użytkownik Richard Yao napisał: > > On Jul 5, 2018, at 4:53 PM, Michał Górny wrote: > > > > Hi, > > > > Here's third version of the patches. I've incorporated the feedback > > so far and reordered the patches (again) to restore their > > degree-of-compatibility order. The full text is included below. > > > > > > Michał Górny (12): > > glep-0063: Use 'OpenPGP' as appropriate > > glep-0063: RSAv4 -> OpenPGP v4 key format > > glep-0063: 'Gentoo subkey' → 'Signing subkey' > > glep-0063: Root key → primary key > > glep-0063: Split out the signing subkey into a separation point > > glep-0063: Explain minimal & recommended sections > > glep-0063: Change the recommended RSA key size to 2048 bits > > glep-0063: Allow ECC curve 25519 keys > > glep-0063: Stop recommending DSA subkeys > > glep-0063: Make 2-yearly expiration term mandatory > > glep-0063: Require renewal 2 weeks before expiration > > glep-0063: Disallow using DSA keys > > > > glep-0063.rst | 97 +-- > > 1 file changed, 64 insertions(+), 33 deletions(-) > > > > > > --- > > GLEP: 63 > > Title: Gentoo OpenPGP policies > > Author: Robin H. Johnson , > >Andreas K. Hüttel , > >Marissa Fischer > > Type: Standards Track > > Status: Final > > Version: 2 > > Created: 2013-02-18 > > Last-Modified: 2018-07-05 > > Post-History: 2013-11-10 > > Content-Type: text/x-rst > > --- > > > > Credits > > === > > > > Many developers and external sources helped in this GLEP. > > > > Abstract > > > > > > This GLEP provides both a minimum requirement and a recommended set of > > OpenPGP key management policies for the Gentoo Linux distribution. > > > > Changes > > === > > > > v2 > > The distinct minimal and recommended expirations have been replaced > > by a single requirement. The rules have been simplified to use > > the same time of 2 years for both the primary key and subkeys. > > > > An additional rule requesting key renewal 2 weeks before expiration > > has been added. This is in order to give services and other developers time > > to refresh the key. > > > > The usage of DSA keys has been disallowed. > > > > v1.1 > > The recommended RSA key size has been changed from 4096 bits > > to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. > > The larger recommendation was unjustified and resulted in people > > unnecessarily replacing their RSA-2048 keys. > > > > Minimal specification has been amended to allow for ECC keys. > > > > The option of using DSA subkey has been removed from recommendations. > > The section now specifies a single recommendation of using RSA. > > > > Motivation > > == > > > > Given the increasing use and importance of cryptographic protocols in > > internet > > transactions of any kind, unified requirements for OpenPGP keys used in > > Gentoo > > Linux development are sorely needed. This document provides both a set of > > bare minimum requirements and a set of best practice recommendations for > > the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. > > It is intended to provide a basis for future improvements such as, e.g., > > consistent ebuild or package signing and verifying by end users. > > > > Specifications for OpenPGP keys > > === > > > > Bare minimum requirements > > - > > This section specifies obligatory requirements for all OpenPGP keys used > > to commit to Gentoo. Keys that do not conform to those requirements can > > not be used to commit. > > > > 1. SHA2-series output digest (SHA1 digests internally permitted), > > 256bit or more:: > > > > personal-digest-preferences SHA256 > > > > 2. Signing subkey that is different from the primary key, and does not > > have any other capabilities enabled. > > > > 3. Primary key and the signing subkey are both of type EITHER: > > > > a. RSA, >=2048 bits (OpenPGP v4 key format or later only) > > > > b. ECC curve 25519 > > > > 4. Expiration date on key and all subkeys set to at most 2 years > > > > 5. Key expiration date renewed at least 2 weeks before the previous > > expiration date. > > > > 6. Upload your key to the SKS keyserver rotation before usage! > > > > Recommendations > > --- > > This section specifies the best practices for Gentoo developers. > > The developers should follow those practices unless there is a strong > > technical reason not to (e.g. hardware limitations, necessity of replacing > > their primary key). > > > > 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append > > the following block:: > > That file no longer exists. > > > > keyserver pool.sks-keyservers.net > > This is less secure than the default according to K_F in #gentoo-infra. > > > > emit-version > > K_F indicated that this harms security too. > > > >
Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update
W dniu pią, 06.07.2018 o godzinie 06∶36 +, użytkownik Robin H. Johnson napisał: > On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote: > > Here's third version of the patches. I've incorporated the feedback > > so far and reordered the patches (again) to restore their > > degree-of-compatibility order. The full text is included below. > > ... > > v2 > > The distinct minimal and recommended expirations have been replaced > > by a single requirement. The rules have been simplified to use > > the same time of 2 years for both the primary key and subkeys. > > -the same time of 2 years ... > +the same 2 year maximum renewal time ... I've changed this as part of different changes, please wait for v4. > > > An additional rule requesting key renewal 2 weeks before expiration > > has been added. This is in order to give services and other developers > > time > > to refresh the key. > > Do we want to state that infra will start contact devs before this, or > keep that as an implementation detail? > > > 4. Expiration date on key and all subkeys set to at most 2 years > > -at most 2 years. > +at most 2 years from generation or refresh of expiry. I've instead went for lengthening the period. > > Recommendations > > --- > > ... > > 3. Key expiration renewed annually > > Can we please suggest it's updated to a fixed day of the year? Done. > > > Gentoo LDAP > > === > > ... > > All Gentoo developers must list the complete fingerprint for their primary > > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex > > digits, > > uppercase, with optional spaces every 8 hex digits. Regular expression for > > validation:: > > Can we please drop the spaces in the field in LDAP. I don't care if we > display it with spaces, but dropping them in LDAP would be helpful. Included an extra commit for this. > > > Copyright > > = > > Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa > > Fischer. > > Please update the copyright date: > 2013,2018 > and add yourself as a copyright owner for the scale of these changes. Done in the first commit. I've also added myself as an Author. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 00/12] GLEP 63 update
> On Jul 5, 2018, at 4:53 PM, Michał Górny wrote: > > Hi, > > Here's third version of the patches. I've incorporated the feedback > so far and reordered the patches (again) to restore their > degree-of-compatibility order. The full text is included below. > > > Michał Górny (12): > glep-0063: Use 'OpenPGP' as appropriate > glep-0063: RSAv4 -> OpenPGP v4 key format > glep-0063: 'Gentoo subkey' → 'Signing subkey' > glep-0063: Root key → primary key > glep-0063: Split out the signing subkey into a separation point > glep-0063: Explain minimal & recommended sections > glep-0063: Change the recommended RSA key size to 2048 bits > glep-0063: Allow ECC curve 25519 keys > glep-0063: Stop recommending DSA subkeys > glep-0063: Make 2-yearly expiration term mandatory > glep-0063: Require renewal 2 weeks before expiration > glep-0063: Disallow using DSA keys > > glep-0063.rst | 97 +-- > 1 file changed, 64 insertions(+), 33 deletions(-) > > > --- > GLEP: 63 > Title: Gentoo OpenPGP policies > Author: Robin H. Johnson , >Andreas K. Hüttel , >Marissa Fischer > Type: Standards Track > Status: Final > Version: 2 > Created: 2013-02-18 > Last-Modified: 2018-07-05 > Post-History: 2013-11-10 > Content-Type: text/x-rst > --- > > Credits > === > > Many developers and external sources helped in this GLEP. > > Abstract > > > This GLEP provides both a minimum requirement and a recommended set of > OpenPGP key management policies for the Gentoo Linux distribution. > > Changes > === > > v2 > The distinct minimal and recommended expirations have been replaced > by a single requirement. The rules have been simplified to use > the same time of 2 years for both the primary key and subkeys. > > An additional rule requesting key renewal 2 weeks before expiration > has been added. This is in order to give services and other developers time > to refresh the key. > > The usage of DSA keys has been disallowed. > > v1.1 > The recommended RSA key size has been changed from 4096 bits > to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. > The larger recommendation was unjustified and resulted in people > unnecessarily replacing their RSA-2048 keys. > > Minimal specification has been amended to allow for ECC keys. > > The option of using DSA subkey has been removed from recommendations. > The section now specifies a single recommendation of using RSA. > > Motivation > == > > Given the increasing use and importance of cryptographic protocols in internet > transactions of any kind, unified requirements for OpenPGP keys used in Gentoo > Linux development are sorely needed. This document provides both a set of > bare minimum requirements and a set of best practice recommendations for > the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. > It is intended to provide a basis for future improvements such as, e.g., > consistent ebuild or package signing and verifying by end users. > > Specifications for OpenPGP keys > === > > Bare minimum requirements > - > This section specifies obligatory requirements for all OpenPGP keys used > to commit to Gentoo. Keys that do not conform to those requirements can > not be used to commit. > > 1. SHA2-series output digest (SHA1 digests internally permitted), > 256bit or more:: > > personal-digest-preferences SHA256 > > 2. Signing subkey that is different from the primary key, and does not > have any other capabilities enabled. > > 3. Primary key and the signing subkey are both of type EITHER: > > a. RSA, >=2048 bits (OpenPGP v4 key format or later only) > > b. ECC curve 25519 > > 4. Expiration date on key and all subkeys set to at most 2 years > > 5. Key expiration date renewed at least 2 weeks before the previous > expiration date. > > 6. Upload your key to the SKS keyserver rotation before usage! > > Recommendations > --- > This section specifies the best practices for Gentoo developers. > The developers should follow those practices unless there is a strong > technical reason not to (e.g. hardware limitations, necessity of replacing > their primary key). > > 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append > the following block:: That file no longer exists. > > keyserver pool.sks-keyservers.net This is less secure than the default according to K_F in #gentoo-infra. > > emit-version K_F indicated that this harms security too. > > default-recipient-self > > # -- All of the below portion from the RiseUp.net OpenPGP best > practices, and > # -- many of them are also in the Debian GPG documentation. > > # when outputting certificates, view user IDs distinctly from keys: > fixed-list-mode > > # long keyids are more collision-resistant than short keyids (it's > trivial to
Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update
>> > 4. Expiration date on key and all subkeys set to at most 2 years >> >> -at most 2 years. >> +at most 2 years from generation or refresh of expiry. > >Now, this won't really work because it's self-propagating date. You're >soon going to see keys with 10 years to expiration because if you >update >the date 5 times from 'refresh of expiry', that's what you get. > >I get what you're trying to say but I can't really think of a sane way >of stating that. Maybe I should just explicitly state '(plus the >period >specified in point 5)'. “The expiry date of the key shall never be more than two years in the future”? -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: killing mediawiki
> On Fri, 6 Jul 2018, Kent Fredric wrote: > On Thu, 5 Jul 2018 12:32:20 -0500 > William Hubbs wrote: >> I looked at this first, and it is very hard on the server. >> Every pull or clone you do to update things works like an initial >> clone, so it takes pretty massive resources. > Surely, then the recommended approach involves: > 1. Selecting pages [1] > 2. Limiting clone depth [2] > Or at least, encouraging the use of by_rev [3] That will change it from being completely unusable to barely usable. Still it isn't something I would want to use on a daily basis. I have tried it when helping with the conversion of the GLEPs. For fetching only, so I don't know what would happen when trying to push a page back to the wiki. Ulrich > 1: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#limit-the-pages-to-be-imported > 2: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#shallow-imports > 3: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#optimizing-git-fetch pgpgSbryKAZip.pgp Description: PGP signature
Re: [gentoo-dev] rfc: killing mediawiki
On Fri, Jul 06, 2018 at 12:34:33PM +1200, Kent Fredric wrote: > On Thu, 5 Jul 2018 12:32:20 -0500 > William Hubbs wrote: > > > I looked at this first, and it is very hard on the server. > > Every pull or clone you do to update things works like an initial clone, > > so it takes pretty massive resources. > > Surely, then the recommended approach involves: > > 1. Selecting pages [1] > 2. Limiting clone depth [2] > > Or at least, encouraging the use of by_rev [3] > > 1: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#limit-the-pages-to-be-imported > 2: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#shallow-imports > 3: > https://github.com/Git-Mediawiki/Git-Mediawiki/blob/master/docs/User-manual.md#optimizing-git-fetch > > There are also other issues I'm not really familiar with because of how mediawiki's error handling works (Patrick could tell you more about this than I can). William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 16∶21 +0200, użytkownik Marc Schiffbauer napisał: > * Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr: > > On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > > > I have my primary key offline only, so renewing/editing it is a much > > > more time consuming matter than if I had my primary key always with me > > > which I consider a bad idea because you do not need to. > > > > But is it sufficiently time-consuming / difficult that it is a problem > > to do it once a year? What do you do when certifying/signing other's UIDs? > > Well, at least its annoying. For me personally it might even be that I > cannot commit to gentoo for some time when the key expired until I have > the chance to update my primary key again. > > And "some time" being somthing between 1 day and several weeks as I am > travelling a lot. > Again, we're talking about once a year. Nobody forces you to wait till it's almost expired to do it. You can practically renew it for 2 more years every time you have the opportunity. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr: > On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > > I have my primary key offline only, so renewing/editing it is a much > > more time consuming matter than if I had my primary key always with me > > which I consider a bad idea because you do not need to. > > But is it sufficiently time-consuming / difficult that it is a problem > to do it once a year? What do you do when certifying/signing other's UIDs? Well, at least its annoying. For me personally it might even be that I cannot commit to gentoo for some time when the key expired until I have the chance to update my primary key again. And "some time" being somthing between 1 day and several weeks as I am travelling a lot. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 06-07-2018 13:34:21 +0200, Ulrich Mueller wrote: > - Make creation of a revocation certificate (and storing it in a place > separate from the key) mandatory. What does this really achieve? Or require? Am I supposed to buy or hire a vault now? -- I'm assuming the word "safe" is missing from above sentence. Side observation: You can't check I have the revocation cert, let alone that you can check where it is stored, or if I lost it. Unless it is stored in a Gentoo owned vault or something, such that infra can invoke it on retirement scripts, this seems like unnecessary bureaucracy. Of course we want to encourage anyone to have a revocation cert, and to store it in a safe place somewhere. This is at best subject to means and opportunities of the person in question. In reality it is quite hard to store secrets securely, even more when they don't fit well in the human SSD. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/06/2018 01:34 PM, Ulrich Mueller wrote: > Note that the revocation certificate is still listed under > recommendations only, so devs need not create one. Making this a > requirement would be a real improvement, IMHO. From a Gentoo perspective, we can "revoke" it by deleting it from LDAP and as such block access to push etc, so it actually is more important for other aspects of the ecosystem than for us. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 13∶34 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Fri, 6 Jul 2018, Marc Schiffbauer wrote: > > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr: > > > If you don't see it for 5 years, how can you be sure that it is > > > even still there? > > Are you serious? Who tells you that I do not check from time to > > time? > > I am sure there will always be some scenario which makes a key > > unacessible in some way. I do not disagree with that. Its a matter > > of propability. > > And for the worst case there is a revoke-Certificate which can be > > used. > > Note that the revocation certificate is still listed under > recommendations only, so devs need not create one. Making this a > requirement would be a real improvement, IMHO. How are you going to enforce it? I didn't make it a requirement because we simply can't verify it being met. > Instead, the GLEP draft is focusing on short expiration times. > It won't help much if your compromised key will expire within one > year, but you cannot revoke it. You're conflating two unrelated concepts. Expiration is not meant to replace revocation, or in any way amend it. Expiration is meant to cover the case of both the key and the revocation certificate being destroyed or otherwise becoming inaccessible. > > Suggestions: > - Change the minimum requirement for key expiry to at most 3 years > (which is what in version 1 is recommended). > - Recommend at most 15 months of key expiry, to be renewed at least > 2 weeks before the expiry date. > - Make creation of a revocation certificate (and storing it in a place > separate from the key) mandatory. > > Ulrich -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
> On Fri, 6 Jul 2018, Marc Schiffbauer wrote: > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr: >> If you don't see it for 5 years, how can you be sure that it is >> even still there? > Are you serious? Who tells you that I do not check from time to > time? > I am sure there will always be some scenario which makes a key > unacessible in some way. I do not disagree with that. Its a matter > of propability. > And for the worst case there is a revoke-Certificate which can be > used. Note that the revocation certificate is still listed under recommendations only, so devs need not create one. Making this a requirement would be a real improvement, IMHO. Instead, the GLEP draft is focusing on short expiration times. It won't help much if your compromised key will expire within one year, but you cannot revoke it. Suggestions: - Change the minimum requirement for key expiry to at most 3 years (which is what in version 1 is recommended). - Recommend at most 15 months of key expiry, to be renewed at least 2 weeks before the expiry date. - Make creation of a revocation certificate (and storing it in a place separate from the key) mandatory. Ulrich pgp6gC2VcLz1v.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > I have my primary key offline only, so renewing/editing it is a much > more time consuming matter than if I had my primary key always with me > which I consider a bad idea because you do not need to. But is it sufficiently time-consuming / difficult that it is a problem to do it once a year? What do you do when certifying/signing other's UIDs? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Michał Górny schrieb am 06.07.18 um 11:33 Uhr: > W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc > Schiffbauer napisał: > > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > > > Schiffbauer napisał: > > > > +1 for 5 years or at least 3. > > > > > > > > Having to renew/edit the key each year seems crazy to me. > > > > > > > > I have my primary key offline only, so renewing/editing it is a much > > > > more time consuming matter than if I had my primary key always with me > > > > which I consider a bad idea because you do not need to. > > > > > > > > > > ...and you consider it a good idea to keep the primary key untouched for > > > 5 years? You don't even know if the medium holding it still works. > > > > Yes. Backup media exists at a different place. > > If you don't see it for 5 years, how can you be sure that it is even > still there? Are you serious? Who tells you that I do not check from time to time? I am sure there will always be some scenario which makes a key unacessible in some way. I do not disagree with that. Its a matter of propability. And for the worst case there is a revoke-Certificate which can be used. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc Schiffbauer napisał: > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > > Schiffbauer napisał: > > > +1 for 5 years or at least 3. > > > > > > Having to renew/edit the key each year seems crazy to me. > > > > > > I have my primary key offline only, so renewing/editing it is a much > > > more time consuming matter than if I had my primary key always with me > > > which I consider a bad idea because you do not need to. > > > > > > > ...and you consider it a good idea to keep the primary key untouched for > > 5 years? You don't even know if the medium holding it still works. > > Yes. Backup media exists at a different place. If you don't see it for 5 years, how can you be sure that it is even still there? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > Schiffbauer napisał: > > +1 for 5 years or at least 3. > > > > Having to renew/edit the key each year seems crazy to me. > > > > I have my primary key offline only, so renewing/editing it is a much > > more time consuming matter than if I had my primary key always with me > > which I consider a bad idea because you do not need to. > > > > ...and you consider it a good idea to keep the primary key untouched for > 5 years? You don't even know if the medium holding it still works. Yes. Backup media exists at a different place. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
[gentoo-dev] Packages / Project up for grabs
Hi, as I want to keep my work on Gentoo focussed, the following packages are up for grabs as I don't use them: app-admin/certmgr app-emulation/hyperd app-emulation/runv dev-haskell/pgp-wordlist dev-haskell/parser-combinators dev-haskell/prettyprinter dev-libs/onigmo dev-python/grafanalib dev-util/goland dev-util/uftrace net-misc/casync sys-apps/habitat In addition, I left the lxqt project, which now is empty. Feel free to join or dissolve it. Thanks, Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration
W dniu pią, 06.07.2018 o godzinie 10∶11 +0200, użytkownik Manuel Rüger napisał: > I disagree with adding this as a requirement. > > Services should explicitly fail to work with expired GPG keys, key > renewal times should be at the key owner's descretion. > This should still be a recommendation that guarantees the key owner to > continue work without interruption. > They do. That is why we need the updates to happen early enough so that the services can sync. It's not nice when Gentoo repository distribution is stalled because a developer changed his key and not all services have synced yet. I've only recently hit the case when my important fix wasn't distributed to users immediately (= more users hit severe breakage) because a developer started using new key before all servers could sync it. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys
On 07/06/2018 07:49 AM, Ulrich Mueller wrote: >> On Thu, 5 Jul 2018, Jonas Stein wrote: > >>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >>> >>> + c. ECC curve 25519 >>> + >>> 4. Key expiry: 5 years maximum >>> 5. Upload your key to the SKS keyserver rotation before usage! > >> I think we should ensure first that everything works fine with ECC. >> Last time I checked, ECC was a nightmare. > >> Some SKS server could not handle ECC... and so on. > > IIRC, it has also been pointed out that ECC is not part of the OpenPGP > standard (yet)? > Right, the NIST curves prime curves are defined in RFC6637 but Curve25519/EdDSA is only implemented in GnuPG and part of the draft rfc4880bis (WG isn't currently active, so not expected a v5 any time soon). ECC is also only implemented in gnupg >=2.1 , so as mentioned earlier, gnupg 1.4 (which is still maintained and often used for smaller footprint or backwards compat to v3 keys) will not be able to use it. > Maybe we should better omit it. It shouldn't be too complicated for > developers to add a dedicated RSA signing key for Gentoo if necessary > (especially, since someone using ECC could be considered an advanced > GnuPG user). If the primary key is ECC, clients not supporting it won't be able to use the key material even if the signing subkey is RSA. > > Ulrich > -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration
I disagree with adding this as a requirement. Services should explicitly fail to work with expired GPG keys, key renewal times should be at the key owner's descretion. This should still be a recommendation that guarantees the key owner to continue work without interruption. Thanks, Manuel On 04.07.2018 12:24, Michał Górny wrote: > Add a rule requesting renewal of keys at least two weeks before their > expiration date, in order to give services time to refresh. > --- > glep-0063.rst | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/glep-0063.rst b/glep-0063.rst > index 7455674..6874b81 100644 > --- a/glep-0063.rst > +++ b/glep-0063.rst > @@ -32,6 +32,10 @@ v2 >specification. Changing the expiration date of existing keys is possible >in-place so there is no need to provide for transitional 'minimum' value. > > + An additional rule requesting key renewal 2 weeks before expiration > + has been added. This is in order to give services and other developers time > + to refresh the key. > + > v1.1 >The recommended RSA key size has been changed from 4096 bits >to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. > @@ -82,7 +86,10 @@ not be used to commit. > > b. Gentoo subkey: 1 year maximum > > -4. Upload your key to the SKS keyserver rotation before usage! > +4. Key expiration date renewed at least 2 weeks before the previous > + expiration date. > + > +5. Upload your key to the SKS keyserver rotation before usage! > > Recommendations > --- > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update
W dniu pią, 06.07.2018 o godzinie 06∶36 +, użytkownik Robin H. Johnson napisał: > On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote: > > Here's third version of the patches. I've incorporated the feedback > > so far and reordered the patches (again) to restore their > > degree-of-compatibility order. The full text is included below. > > ... > > v2 > > The distinct minimal and recommended expirations have been replaced > > by a single requirement. The rules have been simplified to use > > the same time of 2 years for both the primary key and subkeys. > > -the same time of 2 years ... > +the same 2 year maximum renewal time ... > > > An additional rule requesting key renewal 2 weeks before expiration > > has been added. This is in order to give services and other developers > > time > > to refresh the key. > > Do we want to state that infra will start contact devs before this, or > keep that as an implementation detail? Implementation detail. > > > 4. Expiration date on key and all subkeys set to at most 2 years > > -at most 2 years. > +at most 2 years from generation or refresh of expiry. Now, this won't really work because it's self-propagating date. You're soon going to see keys with 10 years to expiration because if you update the date 5 times from 'refresh of expiry', that's what you get. I get what you're trying to say but I can't really think of a sane way of stating that. Maybe I should just explicitly state '(plus the period specified in point 5)'. > > > Recommendations > > --- > > ... > > 3. Key expiration renewed annually > > Can we please suggest it's updated to a fixed day of the year? Sure. > > > Gentoo LDAP > > === > > ... > > All Gentoo developers must list the complete fingerprint for their primary > > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex > > digits, > > uppercase, with optional spaces every 8 hex digits. Regular expression for > > validation:: > > Can we please drop the spaces in the field in LDAP. I don't care if we > display it with spaces, but dropping them in LDAP would be helpful. I'm all for it. I really do wonder how they ended up there in the first place. > > > Copyright > > = > > Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa > > Fischer. > > Please update the copyright date: > 2013,2018 > and add yourself as a copyright owner for the scale of these changes. > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, 06 Jul 2018 08:51:12 +0200 Michał Górny wrote: > W dniu pią, 06.07.2018 o godzinie 06∶28 +, użytkownik Robin H. > Johnson napisał: > > On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote: > > > > option a) > > > > 2 years + N: > > > > 2 weeks <= N <= 3 months. > > > > > > > > option b) > > > > Change the wording to be 'at most 2 years' instead of 'exactly > > > > 2 years'. > > > > > > That *is* the wording. > > > > I apologize. I took ulm's post as canonical and didn't confirm in > > the original GLEP text. > > > > Further change to follow in response to the original text. > > > > > > Separately: > > > > Is two weeks enough time for a new key distribution to users? > > > > > > I originally wanted to specify one month but k_f insisted on > > > something shorter. 2 weeks were the compromise we agreed on. > > > That said, I'd say weekly 'gpg --refresh' is what we should > > > recommend as the bare minimum. > > > > > > That said, the point of two weeks is mostly to give us time to > > > remind developers that their key is expiring and to give them > > > time to actually read their mail and do it before it actually > > > expires. > > > > Please let's start reminding them BEFORE that. I have seen a lot of > > .away files over the last decade, and taking a 2-week offline > > vacation does happen. > > The problem is, Gentoo developers are really hostile people. If you > remind them *before* the term, they are not very nice because how does > someone dare remind very important developer who was planning to do it > week before expiration, and now he needed to waste his precious time > reading your mail. > I never experienced a single developer show or say anything like you are suggesting. Most, thanked me for the reminder whether it was in IRC or email. And since I always cc'd the gkeys alias (most needed changes to meet the spec too), I'm sure Kristian will confirm this. -- Brian Dolbec pgp5aZWnCcqDB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, 06 Jul 2018 08:18:32 +0200 Michał Górny wrote: > W dniu pią, 06.07.2018 o godzinie 06∶08 +, użytkownik Robin H. > Johnson napisał: > > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: > > > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote: > > > > Replace the disjoint 'minimum' and 'recommendation' for > > > > expiration with a single requirement. Make it 2 years. Also, > > > > remove disjoint expiration recommendation for the primary key > > > > and subkeys since many developers fail at implementing that > > > > anyway. > > > > > > Still NACK. If expiration is exactly 2 years and renewal must > > > happen 2 weeks before the expiry date, then it is not possible to > > > keep the same date. > > > > > > Example: The key will expire at 2018-12-31, so it must be renewed > > > at 2018-12-17 or earlier. This will make it impossible to keep > > > the same month and day (unless one would reset it to 2019-12-31, > > > which is only one year though). > > > > > > So please, make it something like 2 years + 3 months. > > > > option a) > > 2 years + N: > > 2 weeks <= N <= 3 months. > > > > option b) > > Change the wording to be 'at most 2 years' instead of 'exactly 2 > > years'. > > That *is* the wording. > > > Separately: > > Is two weeks enough time for a new key distribution to users? > > I originally wanted to specify one month but k_f insisted on something > shorter. 2 weeks were the compromise we agreed on. That said, I'd > say weekly 'gpg --refresh' is what we should recommend as the bare > minimum. > > That said, the point of two weeks is mostly to give us time to remind > developers that their key is expiring and to give them time to > actually read their mail and do it before it actually expires. > I have gkeys spec-check start warning at 30 days, and it has been my experience that often it only gets renewed last minute (depends on how active the developer is. As it is one of those things that gets put off thinking there is still lots of time... But also, many of those had keys that did not meet the spec requirements. -- Brian Dolbec pgphYyrmtOdFC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the required schedule.
>
> So effectively we're down from 5 years to 1 year also for the main
> key, as a mandatory requirement? That is not what I have perceived
> as the consensus in the discussion so far.
No, effectively we have 2 years unless developers are picky, in which
case it's their problem and not mine.
> > I really see no point in added complexity just so that someone could
> > bend the standard to the limits.
>
> It isn't complicated in the current version of GLEP 63 ("5 years
> maximum").
5 years is insane.
> Simply keep that wording, or moderately shorten it, to
> something like 3 years, or 2.25 years. (Or if you prefer round
> numbers, 800 days, or 7000 seconds.) :-)
>
If I do it 3 years, you're going to complain that now you have to update
it every 2 years because it's not 3 years + 2 weeks...
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
W dniu pią, 06.07.2018 o godzinie 06∶28 +, użytkownik Robin H. Johnson napisał: > On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote: > > > option a) > > > 2 years + N: > > > 2 weeks <= N <= 3 months. > > > > > > option b) > > > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'. > > > > That *is* the wording. > > I apologize. I took ulm's post as canonical and didn't confirm in the > original GLEP text. > > Further change to follow in response to the original text. > > > > Separately: > > > Is two weeks enough time for a new key distribution to users? > > > > I originally wanted to specify one month but k_f insisted on something > > shorter. 2 weeks were the compromise we agreed on. That said, I'd say > > weekly 'gpg --refresh' is what we should recommend as the bare minimum. > > > > That said, the point of two weeks is mostly to give us time to remind > > developers that their key is expiring and to give them time to actually > > read their mail and do it before it actually expires. > > Please let's start reminding them BEFORE that. I have seen a lot of > .away files over the last decade, and taking a 2-week offline vacation > does happen. The problem is, Gentoo developers are really hostile people. If you remind them *before* the term, they are not very nice because how does someone dare remind very important developer who was planning to do it week before expiration, and now he needed to waste his precious time reading your mail. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
> On Fri, 06 Jul 2018, Michał Górny wrote:
> Did you even read the text? It's 'at most 2 years'. If you renew it
> every year, you can achieve the desired effect while keeping far
> ahead of the required schedule.
So effectively we're down from 5 years to 1 year also for the main
key, as a mandatory requirement? That is not what I have perceived
as the consensus in the discussion so far.
> I really see no point in added complexity just so that someone could
> bend the standard to the limits.
It isn't complicated in the current version of GLEP 63 ("5 years
maximum"). Simply keep that wording, or moderately shorten it, to
something like 3 years, or 2.25 years. (Or if you prefer round
numbers, 800 days, or 7000 seconds.) :-)
Ulrich
pgpvLl8RgxIzn.pgp
Description: PGP signature
[gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update
On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote: > Here's third version of the patches. I've incorporated the feedback > so far and reordered the patches (again) to restore their > degree-of-compatibility order. The full text is included below. ... > v2 > The distinct minimal and recommended expirations have been replaced > by a single requirement. The rules have been simplified to use > the same time of 2 years for both the primary key and subkeys. -the same time of 2 years ... +the same 2 year maximum renewal time ... > An additional rule requesting key renewal 2 weeks before expiration > has been added. This is in order to give services and other developers time > to refresh the key. Do we want to state that infra will start contact devs before this, or keep that as an implementation detail? > 4. Expiration date on key and all subkeys set to at most 2 years -at most 2 years. +at most 2 years from generation or refresh of expiry. > Recommendations > --- ... > 3. Key expiration renewed annually Can we please suggest it's updated to a fixed day of the year? > Gentoo LDAP > === ... > All Gentoo developers must list the complete fingerprint for their primary > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits, > uppercase, with optional spaces every 8 hex digits. Regular expression for > validation:: Can we please drop the spaces in the field in LDAP. I don't care if we display it with spaces, but dropping them in LDAP would be helpful. > Copyright > = > Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer. Please update the copyright date: 2013,2018 and add yourself as a copyright owner for the scale of these changes. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote: > > option a) > > 2 years + N: > > 2 weeks <= N <= 3 months. > > > > option b) > > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'. > That *is* the wording. I apologize. I took ulm's post as canonical and didn't confirm in the original GLEP text. Further change to follow in response to the original text. > > Separately: > > Is two weeks enough time for a new key distribution to users? > > I originally wanted to specify one month but k_f insisted on something > shorter. 2 weeks were the compromise we agreed on. That said, I'd say > weekly 'gpg --refresh' is what we should recommend as the bare minimum. > > That said, the point of two weeks is mostly to give us time to remind > developers that their key is expiring and to give them time to actually > read their mail and do it before it actually expires. Please let's start reminding them BEFORE that. I have seen a lot of .away files over the last decade, and taking a 2-week offline vacation does happen. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
> On Fri, 6 Jul 2018, Robin H Johnson wrote: > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: >> Still NACK. If expiration is exactly 2 years and renewal must happen >> 2 weeks before the expiry date, then it is not possible to keep the >> same date. >> >> Example: The key will expire at 2018-12-31, so it must be renewed at >> 2018-12-17 or earlier. This will make it impossible to keep the same >> month and day (unless one would reset it to 2019-12-31, which is only >> one year though). >> >> So please, make it something like 2 years + 3 months. > option a) > 2 years + N: > 2 weeks <= N <= 3 months. You don't want the first <= there. If it's 2 years + 2 weeks then devs would have only one exact day for renewal of their key. > option b) > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'. I don't understand. How would this solve the problem? > Separately: > Is two weeks enough time for a new key distribution to users? Ulrich pgpw2GfeNNCb6.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
W dniu pią, 06.07.2018 o godzinie 06∶08 +, użytkownik Robin H. Johnson napisał: > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: > > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote: > > > Replace the disjoint 'minimum' and 'recommendation' for expiration > > > with a single requirement. Make it 2 years. Also, remove disjoint > > > expiration recommendation for the primary key and subkeys since many > > > developers fail at implementing that anyway. > > > > Still NACK. If expiration is exactly 2 years and renewal must happen > > 2 weeks before the expiry date, then it is not possible to keep the > > same date. > > > > Example: The key will expire at 2018-12-31, so it must be renewed at > > 2018-12-17 or earlier. This will make it impossible to keep the same > > month and day (unless one would reset it to 2019-12-31, which is only > > one year though). > > > > So please, make it something like 2 years + 3 months. > > option a) > 2 years + N: > 2 weeks <= N <= 3 months. > > option b) > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'. That *is* the wording. > Separately: > Is two weeks enough time for a new key distribution to users? I originally wanted to specify one month but k_f insisted on something shorter. 2 weeks were the compromise we agreed on. That said, I'd say weekly 'gpg --refresh' is what we should recommend as the bare minimum. That said, the point of two weeks is mostly to give us time to remind developers that their key is expiring and to give them time to actually read their mail and do it before it actually expires. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
W dniu pią, 06.07.2018 o godzinie 07∶43 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote: > > Replace the disjoint 'minimum' and 'recommendation' for expiration > > with a single requirement. Make it 2 years. Also, remove disjoint > > expiration recommendation for the primary key and subkeys since many > > developers fail at implementing that anyway. > > Still NACK. If expiration is exactly 2 years and renewal must happen > 2 weeks before the expiry date, then it is not possible to keep the > same date. Did you even read the text? It's 'at most 2 years'. If you renew it every year, you can achieve the desired effect while keeping far ahead of the required schedule. > Example: The key will expire at 2018-12-31, so it must be renewed at > 2018-12-17 or earlier. This will make it impossible to keep the same > month and day (unless one would reset it to 2019-12-31, which is only > one year though). > > So please, make it something like 2 years + 3 months. > I really see no point in added complexity just so that someone could bend the standard to the limits. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: > > On Thu, 5 Jul 2018, Michał Górny wrote: > > > Replace the disjoint 'minimum' and 'recommendation' for expiration > > with a single requirement. Make it 2 years. Also, remove disjoint > > expiration recommendation for the primary key and subkeys since many > > developers fail at implementing that anyway. > > Still NACK. If expiration is exactly 2 years and renewal must happen > 2 weeks before the expiry date, then it is not possible to keep the > same date. > > Example: The key will expire at 2018-12-31, so it must be renewed at > 2018-12-17 or earlier. This will make it impossible to keep the same > month and day (unless one would reset it to 2019-12-31, which is only > one year though). > > So please, make it something like 2 years + 3 months. option a) 2 years + N: 2 weeks <= N <= 3 months. option b) Change the wording to be 'at most 2 years' instead of 'exactly 2 years'. Separately: Is two weeks enough time for a new key distribution to users? -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
