[gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
--- glep-0063.rst | 4 1 file changed, 4 insertions(+) diff --git a/glep-0063.rst b/glep-0063.rst index f1512b3..8714204 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -33,6 +33,8 @@ v1.1 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. + Motivation == @@ -60,6 +62,8 @@ Bare minimum requirements b. RSA, >=2048 bits (OpenPGP v4 key format or later only) + c. ECC + 3. Key expiry: 5 years maximum 4. Upload your key to the SKS keyserver rotation before usage! -- 2.18.0
Re: [gentoo-dev] rfc: killing mediawiki
On Tue, 3 Jul 2018 12:39:43 -0500 William Hubbs wrote: > I don't care that we have a wiki, but can we please look into killing > mediawiki and look at something with a git backend? It would be very > nice to be able to edit wiki pages in markdown or another similar format > and use git to control the changes instead of editing in a browser. 1. Who are the primary beneficiaries of this suggestion?: a. People with expert knowledge of development systems and people with Gentoo Privileges b. End users who may not be experts, in all things development, but may be able to contribute and consume content. 2. What compromises in flexibility does this create? Eg: Do suggested replacements have capacity to have arbitrary HTML and templating? Or are they restricted to the terribly narrow featureset of Markdown? If you're optimising for 1-a and your choice of compromise results in a reduction in functionality with regards to clear, flexible, and expressive content, it will be hard to sell me on the idea. pgpuiVJqzWy00.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 09:22 AM, Michał Górny wrote: > + c. ECC Likely should not blanket accept ECC for various reasons. For one thing the curves we likely would want to accept are not standardized, so you have interoperability issues. The hardware situation is improving somewhat on these, so that is less of a concern now than back in the day. But there aren't really very strong arguments in favor of ecc, and in the case of quantum computation there less protection offered from ecc due to smaller key sizes. We also keep gnupg 1.4 in tree that does not, and will not, support ecc. -- 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 5/4] glep-0063: Allow ECC keys
W dniu śro, 04.07.2018 o godzinie 09∶49 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 09:22 AM, Michał Górny wrote: > > + c. ECC > > Likely should not blanket accept ECC for various reasons. For one thing > the curves we likely would want to accept are not standardized, so you > have interoperability issues. > > The hardware situation is improving somewhat on these, so that is less > of a concern now than back in the day. > > But there aren't really very strong arguments in favor of ecc, and in > the case of quantum computation there less protection offered from ecc > due to smaller key sizes. > > We also keep gnupg 1.4 in tree that does not, and will not, support ecc. Well, we have developers using ECC (Curve 25519, to be specific). I don't really know enough about this to judge but we either need to allow at least this, or convince those devs to change to RSA. Would one of the following wordings be better: a) ECC, Curve 25519[, ...] b) ECC, curves supported by GnuPG version ... Alternatively, do you have other suggestions? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 09:54 AM, Michał Górny wrote: >> We also keep gnupg 1.4 in tree that does not, and will not, support ecc. > Well, we have developers using ECC (Curve 25519, to be specific). > I don't really know enough about this to judge but we either need to > allow at least this, or convince those devs to change to RSA. incidentally curve25519 is the one I'm thinking of that isn't standardized, although it is part of current draft version of rfc4880bis (but WG is stalled so no update expected any time soon there). NIST/brainpool are included in RFC6637, but we wouldn't want to accept them for various reasons. There are good reasons these are not provided in the regular interface of gnupg, but requires --expert -- 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 5/4] glep-0063: Allow ECC keys
W dniu śro, 04.07.2018 o godzinie 10∶01 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 09:54 AM, Michał Górny wrote: > > > We also keep gnupg 1.4 in tree that does not, and will not, support ecc. > > > > Well, we have developers using ECC (Curve 25519, to be specific). > > I don't really know enough about this to judge but we either need to > > allow at least this, or convince those devs to change to RSA. > > incidentally curve25519 is the one I'm thinking of that isn't > standardized, although it is part of current draft version of rfc4880bis > (but WG is stalled so no update expected any time soon there). > NIST/brainpool are included in RFC6637, but we wouldn't want to accept > them for various reasons. > > There are good reasons these are not provided in the regular interface > of gnupg, but requires --expert > To be honest, I have mixed feelings here. While I agree interoperability is a problem in general, I'm not sure if it's really a problem this large. I agree that we shouldn't recommend ECC but should we ban it entirely? Things to note: 1. I suppose the ECC/cv25519 packets won't change in incompatible manner at this point. 2. Hardware incompatibility issues are not really relevant to us but to the person using the key. 3. Developer keys are mostly for internal use, while the majority of users verify only the infra signatures, so I don't think we have to be that concerned about interoperability of the algos, provided that it works for infra purposes. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 10:42 AM, Michał Górny wrote: > 1. I suppose the ECC/cv25519 packets won't change in incompatible manner > at this point. It being implemented in gnupg-2-2 is a good indication it won't be allowed to change at this point > > 2. Hardware incompatibility issues are not really relevant to us but to > the person using the key. It is relevant to us to the extent of discussion for hardware token for devs > > 3. Developer keys are mostly for internal use, while the majority of > users verify only the infra signatures, so I don't think we have to be > that concerned about interoperability of the algos, provided that it > works for infra purposes. This depends on the discussion of rsync vs git, if you expect end-users to verify git commits from developers directly you require them to use the 2.2 branch, whereby some server users prefer 1.4 for its smaller footprint etc. If we conclude that the git repo is internal and not to be exposed to end-users per se, but distribution happens in curated git or rsync I agree it is not an issue. -- 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 5/4] glep-0063: Allow ECC keys
W dniu śro, 04.07.2018 o godzinie 10∶51 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 10:42 AM, Michał Górny wrote: > > 1. I suppose the ECC/cv25519 packets won't change in incompatible manner > > at this point. > > It being implemented in gnupg-2-2 is a good indication it won't be > allowed to change at this point > > > > > 2. Hardware incompatibility issues are not really relevant to us but to > > the person using the key. > > It is relevant to us to the extent of discussion for hardware token for devs > Sure but I think that's the matter of 'recommended' vs 'minimal'. But that part of the GLEP probably needs to change/be clarified as well. > > > > 3. Developer keys are mostly for internal use, while the majority of > > users verify only the infra signatures, so I don't think we have to be > > that concerned about interoperability of the algos, provided that it > > works for infra purposes. > > This depends on the discussion of rsync vs git, if you expect end-users > to verify git commits from developers directly you require them to use > the 2.2 branch, whereby some server users prefer 1.4 for its smaller > footprint etc. If we conclude that the git repo is internal and not to > be exposed to end-users per se, but distribution happens in curated git I honestly don't think Gentoo is the distribution where we let people stay with obsolete versions for 'smaller footprint'. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
On 07/04/2018 11:09 AM, Michał Górny wrote: > I honestly don't think Gentoo is the distribution where we let people > stay with obsolete versions for 'smaller footprint'. 1.4 isn't obsolete, it is still maintained as separate branch upstream. -- 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
[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update
Hi, everyone. Following comments and other discussion, here's a bigger patch set that updates GLEP 63 to v2. It's divided into three parts: (1) editorial changes (do not change the spec but improve its wording) (2) backwards-compatible changes (existing keys still work) (3) backwards-incompatible changes (minimal spec updates) Each patch comes with a little rationale of its own, so I won't be repeating that here. Additionally, each patch is subject to separate discussion. Depending on the feedback, I might end up presenting those updates for Council approval in smaller parts. -- Best regards, Michał Górny Michał Górny (11): glep-0063: Use 'OpenPGP' as appropriate glep-0063: RSAv4 -> OpenPGP v4 key format glep-0063: Clarify dedicated signing subkey in minimal reqs glep-0063: Root key → primary key 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 recommended expiration terms mandatory glep-0063: Require renewal 2 weeks before expiration glep-0063: Disallow using DSA keys glep-0063.rst | 98 +++ 1 file changed, 67 insertions(+), 31 deletions(-) -- 2.18.0
[gentoo-dev] [PATCH v2 01/11] 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 | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index c59d545..dd61ecc 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -1,6 +1,6 @@ --- GLEP: 63 -Title: Gentoo GPG key policies +Title: Gentoo OpenPGP policies Author: Robin H. Johnson , Andreas K. Hüttel , Marissa Fischer @@ -8,7 +8,7 @@ Type: Standards Track Status: Final Version: 1 Created: 2013-02-18 -Last-Modified: 2015-08-25 +Last-Modified: 2018-07-02 Post-History: 2013-11-10 Content-Type: text/x-rst --- @@ -21,22 +21,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 +125,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:: -- 2.18.0
[gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
Reword the minimal requirements to clearly indicate that a dedicated signing subkey is required. The current wording may make it unclear whether the 'root key' and 'signing subkey' can be the same key. --- glep-0063.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glep-0063.rst b/glep-0063.rst index 8e4f0d5..0082edd 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -45,7 +45,7 @@ Bare minimum requirements personal-digest-preferences SHA256 -2. Root key and signing subkey of EITHER: +2. Root key and a dedicated signing subkey, both of EITHER: a. DSA, 2048-bit -- 2.18.0
[gentoo-dev] [PATCH v2 02/11] 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 dd61ecc..8e4f0d5 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -49,7 +49,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 @@ -101,7 +101,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 v2 04/11] 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 | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 0082edd..2a5e02f 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -8,7 +8,7 @@ Type: Standards Track Status: Final Version: 1 Created: 2013-02-18 -Last-Modified: 2018-07-02 +Last-Modified: 2018-07-04 Post-History: 2013-11-10 Content-Type: text/x-rst --- @@ -45,7 +45,7 @@ Bare minimum requirements personal-digest-preferences SHA256 -2. Root key and a dedicated signing subkey, both of EITHER: +2. Primary key and a dedicated signing subkey, both of EITHER: a. DSA, 2048-bit @@ -101,7 +101,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. @@ -113,7 +113,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. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. @@ -125,7 +125,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 v2 05/11] 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 2a5e02f..4c22fbe 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -40,6 +40,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:: @@ -57,6 +61,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 v2 06/11] 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 | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 4c22fbe..6dc4ce5 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -6,7 +6,7 @@ Author: Robin H. Johnson , Marissa Fischer Type: Standards Track Status: Final -Version: 1 +Version: 1.1 Created: 2013-02-18 Last-Modified: 2018-07-04 Post-History: 2013-11-10 @@ -24,6 +24,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 == @@ -109,7 +118,7 @@ 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) +2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later) This may require creating an entirely new key. @@ -117,7 +126,7 @@ their primary key). a. DSA 2048 bits exactly. - b. RSA 4096 bits exactly. + b. RSA 2048 bits exactly. 4. Key expiry: @@ -170,6 +179,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 v2 07/11] glep-0063: Allow ECC, curve 25519 keys
Optionally allow using ECC, curve 25519 keys. We already have developers using those keys, and given that they are supported by GnuPG 2.2, there's probably no reason to ban them. However, they're not recommended due to interoperability issues. --- glep-0063.rst | 4 1 file changed, 4 insertions(+) diff --git a/glep-0063.rst b/glep-0063.rst index 6dc4ce5..ab7cb79 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -33,6 +33,8 @@ v1.1 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. + Motivation == @@ -64,6 +66,8 @@ not be used to commit. b. RSA, >=2048 bits (OpenPGP v4 key format or later only) + c. ECC, curve 25519 + 3. Key expiry: 5 years maximum 4. Upload your key to the SKS keyserver rotation before usage! -- 2.18.0
[gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
Given that the key expiration can be updated in place, there is no reason to provide separate 'minimal' and 'recommended' values. --- glep-0063.rst | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index e81c862..7455674 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -6,7 +6,7 @@ Author: Robin H. Johnson , Marissa Fischer Type: Standards Track Status: Final -Version: 1.1 +Version: 2 Created: 2013-02-18 Last-Modified: 2018-07-04 Post-History: 2013-11-10 @@ -27,6 +27,11 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2 + The recommended key expiration rules have been moved to the minimal + specification. Changing the expiration date of existing keys is possible + in-place so there is no need to provide for transitional 'minimum' value. + 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]_. @@ -71,7 +76,11 @@ not be used to commit. c. ECC, curve 25519 -3. Key expiry: 5 years maximum +3. Key expiration: + + a. Primary key: 3 years maximum + + b. Gentoo subkey: 1 year maximum 4. Upload your key to the SKS keyserver rotation before usage! @@ -128,11 +137,11 @@ their primary key). 2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits (OpenPGP v4 key format or later) -3. Key expiry: +3. Key expiration renewal: - a. Primary key: 3 years maximum, expiry date renewed annually. + a. Primary key: annual - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. + b. Gentoo subkey: every 6 months 4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -- 2.18.0
[gentoo-dev] [PATCH v2 08/11] glep-0063: Stop recommending DSA subkeys
There is really no technical reason to use DSA these days, and we should focus on having a single recommendation. DSA keys are still permitted via 'minimal' requirements. --- glep-0063.rst | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index ab7cb79..e81c862 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -35,6 +35,9 @@ v1.1 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 == @@ -122,26 +125,19 @@ 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, 2048 bits (OpenPGP v4 key format or later) - - This may require creating an entirely new key. - -3. Dedicated signing subkey of EITHER: - - a. DSA 2048 bits exactly. - - b. RSA 2048 bits exactly. +2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits + (OpenPGP v4 key format or later) -4. Key expiry: +3. Key expiry: a. Primary key: 3 years maximum, expiry date renewed annually. b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. -5. Create a revocation certificate & store it hardcopy offsite securely +4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -6. Encrypted backup of your secret keys. +5. Encrypted backup of your secret keys. Gentoo LDAP === -- 2.18.0
[gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration
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 --- -- 2.18.0
[gentoo-dev] [PATCH v2 11/11] glep-0063: Disallow using DSA keys
There really is no technical reason to use DSA keys and people who are still using old DSA keys should finally replace them, so remove them from the minimal requirements. --- glep-0063.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 6874b81..cd132a6 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -36,6 +36,8 @@ v2 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]_. @@ -74,11 +76,9 @@ not be used to commit. 2. Primary key and a dedicated signing subkey, both of EITHER: - a. DSA, 2048-bit - - b. RSA, >=2048 bits (OpenPGP v4 key format or later only) + a. RSA, >=2048 bits (OpenPGP v4 key format or later only) - c. ECC, curve 25519 + b. ECC, curve 25519 3. Key expiration: -- 2.18.0
[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
W dniu śro, 04.07.2018 o godzinie 12∶23 +0200, użytkownik Michał Górny napisał: > Hi, everyone. > > Following comments and other discussion, here's a bigger patch set > that updates GLEP 63 to v2. And of course I forgot to include the full text. Here it is: --- 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-04 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 recommended key expiration rules have been moved to the minimal 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. 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. Primary key and a dedicated signing subkey, both of EITHER: a. RSA, >=2048 bits (OpenPGP v4 key format or later only) b. ECC, curve 25519 3. Key expiration: a. Primary key: 3 years maximum b. Gentoo subkey: 1 year maximum 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 --- 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:: keyserver pool.sks-keyservers.net emit-version 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 make a key # with any desired short keyid) # NOTE: this breaks kmail gnupg support! keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to # the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) sig-notation issuer-...
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:23 PM, Michał Górny wrote: > -2. Root key and signing subkey of EITHER: > +2. Root key and a dedicated signing subkey, both of EITHER: "dedicated" here might be misread to be gentoo-specific, which doesn't really make much sense. -- 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 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 12:23 PM, Michał Górny wrote: > > -2. Root key and signing subkey of EITHER: > > +2. Root key and a dedicated signing subkey, both of EITHER: > > "dedicated" here might be misread to be gentoo-specific, which doesn't > really make much sense. What alternative do you suggest? We really want to make clear that we require a separate subkey, and that subkey is not marked for encryption. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:54 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > Fiskerstrand napisał: >> On 07/04/2018 12:23 PM, Michał Górny wrote: >>> -2. Root key and signing subkey of EITHER: >>> +2. Root key and a dedicated signing subkey, both of EITHER: >> >> "dedicated" here might be misread to be gentoo-specific, which doesn't >> really make much sense. > > What alternative do you suggest? We really want to make clear that we > require a separate subkey, and that subkey is not marked for encryption. > "signing subkey" already implies as much though, but maybe write it out more "Both the primary key and the signing subkey needs to be of EITHER;" -- 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 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
W dniu śro, 04.07.2018 o godzinie 12∶58 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 12:54 PM, Michał Górny wrote: > > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > > Fiskerstrand napisał: > > > On 07/04/2018 12:23 PM, Michał Górny wrote: > > > > -2. Root key and signing subkey of EITHER: > > > > +2. Root key and a dedicated signing subkey, both of EITHER: > > > > > > "dedicated" here might be misread to be gentoo-specific, which doesn't > > > really make much sense. > > > > What alternative do you suggest? We really want to make clear that we > > require a separate subkey, and that subkey is not marked for encryption. > > > > "signing subkey" already implies as much though, but maybe write it out > more "Both the primary key and the signing subkey needs to be of EITHER;" > Or maybe even make a separate point about having a separate signing subkey? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 07/04/2018 12:59 PM, Michał Górny wrote: > > Or maybe even make a separate point about having a separate signing > subkey? > Right, that is likely also easier to understand. -- 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
[gentoo-dev] Package up for grabs: sys-apps/pacman
Dear all, sys-apps/pacman[1] is up for grabs after my retirement as the proxied maintainer for it. There are open bugs[2], but I would consider the package in a relatively good shape. Some people seem to be already interested in proxied maintenance - please coordinate with them. For details take a look at the latest bump bug[3]. Best regards, Nils Freydank Links: [1] https://packages.gentoo.org/packages/sys-apps/pacman [2] https://bugs.gentoo.org/buglist.cgi?quicksearch=sys-apps%2Fpacman&list_id=3981994 [3] https://bugs.gentoo.org/659474#c1 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 12:23 PM, Michał Górny wrote: > > -2. Root key and signing subkey of EITHER: > > +2. Root key and a dedicated signing subkey, both of EITHER: > > "dedicated" here might be misread to be gentoo-specific, which doesn't > really make much sense. > Hmm, actually the recommended spec already talks of 'dedicated', so I'll change it as an additional commit rather than in place. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: killing mediawiki
On Wed, 4 Jul 2018 19:21:53 +1200 Kent Fredric wrote: > On Tue, 3 Jul 2018 12:39:43 -0500 > William Hubbs wrote: > > > I don't care that we have a wiki, but can we please look into > > killing mediawiki and look at something with a git backend? It > > would be very nice to be able to edit wiki pages in markdown or > > another similar format and use git to control the changes instead > > of editing in a browser. > > 1. Who are the primary beneficiaries of this suggestion?: > > a. People with expert knowledge of development systems and people > with Gentoo Privileges > > b. End users who may not be experts, in all things development, but > may be able to contribute and consume content. > > 2. What compromises in flexibility does this create? Eg: Do suggested >replacements have capacity to have arbitrary HTML and templating? > Or are they restricted to the terribly narrow featureset of Markdown? > > > If you're optimising for 1-a and your choice of compromise results in > a reduction in functionality with regards to clear, flexible, and > expressive content, it will be hard to sell me on the idea. > 3) The ability of someone with a sight disability, the actual ability to contribute to the project. We as a project should try make our documentation accessible to as broad an audience as possible. I know from personal experience and having worked with such a person, to make it possible to work with cli tools to be able to interact with normally browser only visual interfaces which are extremely poor to work with using a screen reader. At my work, I personally made a github python library and cli interface for github, and worked to create templates for a go-jira command line interface so a visually impaired co-worker could interact with those systems. -- Brian Dolbec pgp2ADbD_1YTy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 18-07-04 12:54:50, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > Fiskerstrand napisał: > > On 07/04/2018 12:23 PM, Michał Górny wrote: > > > -2. Root key and signing subkey of EITHER: > > > +2. Root key and a dedicated signing subkey, both of EITHER: > > > > "dedicated" here might be misread to be gentoo-specific, which doesn't > > really make much sense. > > What alternative do you suggest? We really want to make clear that we > require a separate subkey, and that subkey is not marked for encryption. > I'd suggest something along the lines of 'subkey with signing only capabilitiyies' or 'signing only subkey'. I state this because you are able to have a combined SE subkey which would match the language of dedicated or simply only saying 'signing subkey'. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: killing mediawiki
On Wed, Jul 04, 2018 at 07:21:53PM +1200, Kent Fredric wrote: > On Tue, 3 Jul 2018 12:39:43 -0500 > William Hubbs wrote: > > > I don't care that we have a wiki, but can we please look into killing > > mediawiki and look at something with a git backend? It would be very > > nice to be able to edit wiki pages in markdown or another similar format > > and use git to control the changes instead of editing in a browser. > > 1. Who are the primary beneficiaries of this suggestion?: > > a. People with expert knowledge of development systems and people > with Gentoo Privileges > > b. End users who may not be experts, in all things development, but > may be able to contribute and consume content. Anyone really could benefit from it. The replacements are wikis, so if you want to edit via the web like you do now, that's still available. > > 2. What compromises in flexibility does this create? Eg: Do suggested >replacements have capacity to have arbitrary HTML and templating? Or >are they restricted to the terribly narrow featureset of Markdown? Several of them support multiple formats, so that would depend on the replacement chosen. > If you're optimising for 1-a and your choice of compromise results in a > reduction in functionality with regards to clear, flexible, and > expressive content, it will be hard to sell me on the idea. Yes I would benefit from this change, but it is not a case of optimizing for one. It is a case of opening up the use of the wiki to the largest audiance possible. This is just good universal design. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: killing mediawiki
On Tue, Jul 03, 2018 at 10:31:20PM -0400, Matt Turner wrote: > On Tue, Jul 3, 2018 at 1:39 PM William Hubbs wrote: > > > > All, > > > > some of us have talked about this on IRC off and on, but I want to bring > > it up here as well. > > > > I don't care that we have a wiki, but can we please look into killing > > mediawiki and look at something with a git backend? It would be very > > nice to be able to edit wiki pages in markdown or another similar format > > and use git to control the changes instead of editing in a browser. > > I assume that your primary reason for wanting to replace mediawiki is > to improve accessibility. I suggest you state that more clearly when > making such a proposal. Everyone would benefit, so it isn't specifically tied to that. I see it more tied to universal design, which accessibility is a part of. If you want to edit with a browser like you do now, you would be able to continue doing that. But, if you want to edit files locally and use git to push your changes, that would be an option as well. William signature.asc Description: Digital signature
[gentoo-dev] Lastrites: app-crypt/gkeys-gen
# Brian Dolbec (4 July 2018) # No longer needed, newer app-crypt/gnupg-2 versions have simple cli options # for generating new keys and doing key maintenance. Removal in a month app-crypt/gkeys-gen -- Brian Dolbec
[gentoo-dev] [PATCH 12/13] glep-0063: 'Gentoo subkey' → 'Signing subkey'
Remove the last occurence that might suggest that developers are expected to use a dedicated subkey for Gentoo. Suggested-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 cd132a6..d3e12e0 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -84,7 +84,7 @@ not be used to commit. a. Primary key: 3 years maximum - b. Gentoo subkey: 1 year maximum + b. Signing subkey: 1 year maximum 4. Key expiration date renewed at least 2 weeks before the previous expiration date. @@ -148,7 +148,7 @@ their primary key). a. Primary key: annual - b. Gentoo subkey: every 6 months + b. Signing subkey: every 6 months 4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -- 2.18.0
[gentoo-dev] [PATCH 13/13] glep-0063: Split out the signing subkey into a separation 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 | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index d3e12e0..2f4e7f8 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -74,22 +74,25 @@ not be used to commit. personal-digest-preferences SHA256 -2. Primary key and a dedicated signing subkey, both 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. RSA, >=2048 bits (OpenPGP v4 key format or later only) b. ECC, curve 25519 -3. Key expiration: +4. Key expiration: a. Primary key: 3 years maximum b. Signing subkey: 1 year maximum -4. Key expiration date renewed at least 2 weeks before the previous +5. Key expiration date renewed at least 2 weeks before the previous expiration date. -5. Upload your key to the SKS keyserver rotation before usage! +6. Upload your key to the SKS keyserver rotation before usage! Recommendations --- @@ -141,7 +144,7 @@ their primary key). # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 -2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits +2. Primary key and the signing subkey are both of type RSA, 2048 bits (OpenPGP v4 key format or later) 3. Key expiration renewal: -- 2.18.0
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
Updated complete text after applying two more patches on k_f's request. --- 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-04 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 recommended key expiration rules have been moved to the minimal 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. 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. Key expiration: a. Primary key: 3 years maximum b. Signing subkey: 1 year maximum 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:: keyserver pool.sks-keyservers.net emit-version 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 make a key # with any desired short keyid) # NOTE: this breaks kmail gnupg support! keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to # the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g # when making an OpenPGP cer
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
> On Wed, 4 Jul 2018, Michał Górny wrote: > -3. Key expiry: 5 years maximum > +3. Key expiration: > + > + a. Primary key: 3 years maximum > + > + b. Gentoo subkey: 1 year maximum What problem are you trying to solve here? Ulrich pgpfeO7ifif_W.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
> On Wed, 04 Jul 2018, Michał Górny wrote: >b. Signing subkey: 1 year maximum > 5. Key expiration date renewed at least 2 weeks before the previous >expiration date. This is crappy as a scheme, since it will make it impossible to keep the expiration date at a constant month and date. Ulrich pgpFK0sjc6DBj.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Wed, 4 Jul 2018, Michał Górny wrote: > > -3. Key expiry: 5 years maximum > > +3. Key expiration: > > + > > + a. Primary key: 3 years maximum > > + > > + b. Gentoo subkey: 1 year maximum > > What problem are you trying to solve here? > The problem of having unjustified double standards. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Wed, 04 Jul 2018, Michał Górny wrote: > >b. Signing subkey: 1 year maximum > > 5. Key expiration date renewed at least 2 weeks before the previous > >expiration date. > > This is crappy as a scheme, since it will make it impossible to keep > the expiration date at a constant month and date. > Nobody forces you to prolong it for exactly the same amount, exactly two weeks before expiration. The only point made here is to give services time to sync rather than the common combo of renewing key once it already expired. Especially, if you follow the recommended scheme below you can easily get periodic expiration dates. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 05/10] xdg.eclass: make EAPI 7 ready
On Wed, Jun 27, 2018 at 08:37:04AM +0200, Michał Górny wrote: > W dniu śro, 27.06.2018 o godzinie 06∶58 +0200, użytkownik Ulrich Mueller > napisał: > > > > > > > On Tue, 26 Jun 2018, Marty E Plummer wrote: > > > Add dev-util/desktop-file-utils and x11-misc/shared-mime-info to BDEPEND > > > as a number of executables which will need to be executed on the build > > > host are included in them. > > > Package-Manager: Portage-2.3.40, Repoman-2.3.9 > > > --- > > > eclass/xdg.eclass | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > diff --git a/eclass/xdg.eclass b/eclass/xdg.eclass > > > index 2a4e1f81abf..fc4bee30ca5 100644 > > > --- a/eclass/xdg.eclass > > > +++ b/eclass/xdg.eclass > > > @@ -26,6 +26,7 @@ DEPEND=" > > > dev-util/desktop-file-utils > > > x11-misc/shared-mime-info > > > " > > > +[[ ${EAPI:-0} == [0123456] ]] || BDEPEND="${DEPEND}" > > > > Are these also needed in DEPEND? If not, you should set DEPEND="" in > > EAPI 7. > > > > Technically, they don't belong in either because they're run > in pkg_post* phases only. > https://projects.gentoo.org/pms/7/pms.html#x1-680008.1 According to this, if I read it right, pkg_{pre,post}{inst,rm} deps should go into PDEPEND; is that still correct in terms of EAPI7 and such? > -- > Best regards, > Michał Górny
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On Wed, Jul 04, 2018 at 11:12:31PM +0200, Ulrich Mueller wrote: > > On Wed, 04 Jul 2018, Michał Górny wrote: > > >b. Signing subkey: 1 year maximum > > > 5. Key expiration date renewed at least 2 weeks before the previous > >expiration date. > This is crappy as a scheme, since it will make it impossible to keep > the expiration date at a constant month and date. Why will it make things difficult? In the expire prompt, you CAN specify an exact expire date or timestamp. Only catch is that if I was doing it 2 weeks before, I'd want to push it out another year or 6 months (depending on what), so it would briefly be valid for 54 weeks. -- 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 v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:28 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller > napisał: >>> On Wed, 04 Jul 2018, Michał Górny wrote: >>>b. Signing subkey: 1 year maximum >>> 5. Key expiration date renewed at least 2 weeks before the previous >>>expiration date. >> >> This is crappy as a scheme, since it will make it impossible to keep >> the expiration date at a constant month and date. >> > > Nobody forces you to prolong it for exactly the same amount, exactly two > weeks before expiration. The only point made here is to give services > time to sync rather than the common combo of renewing key once it > already expired. > > Especially, if you follow the recommended scheme below you can easily > get periodic expiration dates. > As I understand ulm's concern, the issue is with the max 1 year in combination with this, e.g it effectively prohibits extended a subkey expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds one year maximum -- 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 00/11] Major GLEP 63 update; full text
> On Wed, 4 Jul 2018, Robin H Johnson wrote: >> >b. Signing subkey: 1 year maximum >> >> > 5. Key expiration date renewed at least 2 weeks before the >> >previous expiration date. > Only catch is that if I was doing it 2 weeks before, I'd want to > push it out another year or 6 months (depending on what), so it > would briefly be valid for 54 weeks. Exactly, and that would be forbidden by the new policy. Also I don't see why a shorter expiry of the subkey should be mandatory. Has the current policy (which permits same expiry of main key and subkey) caused any issues in the past? Ulrich pgpJfluJIM0_V.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:43 PM, Kristian Fiskerstrand wrote: > On 07/04/2018 11:28 PM, Michał Górny wrote: >> W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller >> napisał: On Wed, 04 Jul 2018, Michał Górny wrote: b. Signing subkey: 1 year maximum 5. Key expiration date renewed at least 2 weeks before the previous expiration date. >>> >>> This is crappy as a scheme, since it will make it impossible to keep >>> the expiration date at a constant month and date. >>> >> >> Nobody forces you to prolong it for exactly the same amount, exactly two >> weeks before expiration. The only point made here is to give services >> time to sync rather than the common combo of renewing key once it >> already expired. >> >> Especially, if you follow the recommended scheme below you can easily >> get periodic expiration dates. >> > > As I understand ulm's concern, the issue is with the max 1 year in > combination with this, e.g it effectively prohibits extended a subkey > expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds > one year maximum > fwiw, this can be mitigated by allowing e.g 1.25 years / 15 months instead of one year. -- 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
On 7/4/2018 5:24 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller > napisał: >>> On Wed, 4 Jul 2018, Michał Górny wrote: >>> -3. Key expiry: 5 years maximum >>> +3. Key expiration: >>> + >>> + a. Primary key: 3 years maximum >>> + >>> + b. Gentoo subkey: 1 year maximum >> >> What problem are you trying to solve here? >> > > The problem of having unjustified double standards. IMHO, one year for a signing subkey is too short. I see no problem with three years like the primary key. Especially since people will typically just change the expiration and advance it the minimum number of years, lather, rinse, and repeat. It's a solution looking for a problem. NAK on this. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys
On 7/4/2018 6:23 AM, Michał Górny wrote: > Optionally allow using ECC, curve 25519 keys. We already have > developers using those keys, and given that they are supported > by GnuPG 2.2, there's probably no reason to ban them. However, they're > not recommended due to interoperability issues. > --- > glep-0063.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/glep-0063.rst b/glep-0063.rst > index 6dc4ce5..ab7cb79 100644 > --- a/glep-0063.rst > +++ b/glep-0063.rst > @@ -33,6 +33,8 @@ v1.1 >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. > + > Motivation > == > > @@ -64,6 +66,8 @@ not be used to commit. > > b. RSA, >=2048 bits (OpenPGP v4 key format or later only) > > + c. ECC, curve 25519 > + > 3. Key expiry: 5 years maximum > > 4. Upload your key to the SKS keyserver rotation before usage! > Add a minimum key size here for ECC. They have different bit sizes than classic DSA/RSA keys. A quick read indicates that a 224-bit ECC key is roughly equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is equivalent to, so the logical minimum for ECC looks like 'nistp256'. The maximum is 521-bits on ECC (nistp521). Also move the mention of Ed25519 keys to their own bullet and clarify that they don't allow for a key length, as I think that's hardcoded in some capacity. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys
On 07/05/2018 01:07 AM, Joshua Kinard wrote: >> @@ -64,6 +66,8 @@ not be used to commit. >> >> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >> >> + c. ECC, curve 25519 >> + >> 3. Key expiry: 5 years maximum >> >> 4. Upload your key to the SKS keyserver rotation before usage! >> > Add a minimum key size here for ECC. They have different bit sizes than > classic DSA/RSA keys. A quick read indicates that a 224-bit ECC key is > roughly > equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is > equivalent to, so the logical minimum for ECC looks like 'nistp256'. The > maximum is 521-bits on ECC (nistp521). > > Also move the mention of Ed25519 keys to their own bullet and clarify that > they > don't allow for a key length, as I think that's hardcoded in some capacity. following the comma-style of the rest of the document, the ECC part should likely be read as curve25519 being the only acceptable curve, which is 256 bits (roughtly 128 bit shannon entropy equivalent) that said, I'm not aware of any curves defined with a lower security margin than this for OpenPGP in general. The known curves in the ecosystem are let oid_to_psize oid = let psize = match oid with | "\x2b\x81\x04\x00\x23" -> 521(* nistp521 *) | "\x2b\x81\x04\x00\x22" -> 384(* nistp384 *) | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256(* nistp256 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256(* brainpoolP256r1 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384(* brainpoolP384r1 *) | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512(* brainpoolP512r1 *) | "\x2b\x81\x04\x00\x0a" -> 256(* secp256k1 *) | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256(* Ed25519 *) | _ -> failwith "Unknown OID" -- 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 07/11] glep-0063: Allow ECC, curve 25519 keys
On 07/05/2018 01:22 AM, Kristian Fiskerstrand wrote: > that said, I'm not aware of any curves defined with a lower security > margin than this for OpenPGP in general. The known curves in the > ecosystem are known in the ecosystem being the union of rfc4880bis draft and rfc6637 -- 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 07/11] glep-0063: Allow ECC, curve 25519 keys
On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote: > On 07/05/2018 01:07 AM, Joshua Kinard wrote: >>> @@ -64,6 +66,8 @@ not be used to commit. >>> >>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >>> >>> + c. ECC, curve 25519 >>> + >>> 3. Key expiry: 5 years maximum >>> >>> 4. Upload your key to the SKS keyserver rotation before usage! >>> >> Add a minimum key size here for ECC. They have different bit sizes than >> classic DSA/RSA keys. A quick read indicates that a 224-bit ECC key is >> roughly >> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is >> equivalent to, so the logical minimum for ECC looks like 'nistp256'. The >> maximum is 521-bits on ECC (nistp521). >> >> Also move the mention of Ed25519 keys to their own bullet and clarify that >> they >> don't allow for a key length, as I think that's hardcoded in some capacity. > > following the comma-style of the rest of the document, the ECC part > should likely be read as curve25519 being the only acceptable curve, > which is 256 bits (roughtly 128 bit shannon entropy equivalent) > > that said, I'm not aware of any curves defined with a lower security > margin than this for OpenPGP in general. The known curves in the > ecosystem are > > let oid_to_psize oid = >let psize = match oid with > | "\x2b\x81\x04\x00\x23" -> 521 (* nistp521 *) > | "\x2b\x81\x04\x00\x22" -> 384 (* nistp384 *) > | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256 (* nistp256 *) > | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256 (* brainpoolP256r1 *) > | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384 (* brainpoolP384r1 *) > | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512 (* brainpoolP512r1 *) > | "\x2b\x81\x04\x00\x0a" -> 256 (* secp256k1 *) > | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256 (* Ed25519 *) > | _ -> failwith "Unknown OID" > By "only acceptable curve", do you mean we shouldn't allow the nistp* key types, only Ed25519? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: killing mediawiki
>> some of us have talked about this on IRC off and on, but I want to bring >> it up here as well. >> >> I don't care that we have a wiki, but can we please look into killing >> mediawiki and look at something with a git backend? It would be very >> nice to be able to edit wiki pages in markdown or another similar format >> and use git to control the changes instead of editing in a browser. > > I assume that your primary reason for wanting to replace mediawiki is > to improve accessibility. I suggest you state that more clearly when > making such a proposal. I see. Is it possible to improve the accessibility for mediawiki and do we have volunteers to do that? -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: killing mediawiki
On Wed, 4 Jul 2018 12:44:11 -0500 William Hubbs wrote: > Yes I would benefit from this change, but it is not a case of optimizing > for one. It is a case of opening up the use of the wiki to the largest > audiance possible. This is just good universal design. Unfortunately, my experience with wiki's indicates that's not really an option we have. There are lots of different formats, sure, but lots of those formats reduce to being restrictive, declarative formats, where "content" is stuffed into a range of formats predefined in the markups syntax. This ultimately ends up *restricting* the range of *visual* tools at our disposal for distinguishing details on a case-by-case basis, by forcing all details to adhere to a universally simplified scheme. While I do appreciate the difficulty presented to people with sight-impairment, I'd opt primarily for choices that help them *without* compromising the range of options we have for visual distinguishers. Just as it stands, a syntax that is represented as a simplification of HTML via templates, where new terms can be created in terms of HTML, and where raw HTML can be used in a pinch, tends to make the best of these options for unimpaired people. Its a shitty situation all round really, because as best as I can tell, there's no choice without some painful compromise for somebody. So while a universal design is an admirable goal, I fear in practice it will have the same results as what "universal interfaces" achieve: A reduction in net functionality because the more interesting/advanced functionality is out of the reach of some users. ( Yes, yes, I'm aware of my sight-privilege talking ) pgpJsb4iekax9.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys
On Wed, Jul 4, 2018 at 7:18 PM, Joshua Kinard wrote: > On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote: >> On 07/05/2018 01:07 AM, Joshua Kinard wrote: @@ -64,6 +66,8 @@ not be used to commit. b. RSA, >=2048 bits (OpenPGP v4 key format or later only) + c. ECC, curve 25519 + 3. Key expiry: 5 years maximum 4. Upload your key to the SKS keyserver rotation before usage! >>> Add a minimum key size here for ECC. They have different bit sizes than >>> classic DSA/RSA keys. A quick read indicates that a 224-bit ECC key is >>> roughly >>> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is >>> equivalent to, so the logical minimum for ECC looks like 'nistp256'. The >>> maximum is 521-bits on ECC (nistp521). >>> >>> Also move the mention of Ed25519 keys to their own bullet and clarify that >>> they >>> don't allow for a key length, as I think that's hardcoded in some capacity. >> >> following the comma-style of the rest of the document, the ECC part >> should likely be read as curve25519 being the only acceptable curve, >> which is 256 bits (roughtly 128 bit shannon entropy equivalent) >> >> that said, I'm not aware of any curves defined with a lower security >> margin than this for OpenPGP in general. The known curves in the >> ecosystem are >> >> let oid_to_psize oid = >>let psize = match oid with >> | "\x2b\x81\x04\x00\x23" -> 521 (* nistp521 *) >> | "\x2b\x81\x04\x00\x22" -> 384 (* nistp384 *) >> | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256 (* nistp256 *) >> | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256 (* brainpoolP256r1 *) >> | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384 (* brainpoolP384r1 *) >> | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512 (* brainpoolP512r1 *) >> | "\x2b\x81\x04\x00\x0a" -> 256 (* secp256k1 *) >> | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256 (* Ed25519 *) >> | _ -> failwith "Unknown OID" >> > > By "only acceptable curve", do you mean we shouldn't allow the nistp* key > types, only Ed25519? > Yes, the NIST curves are extremely suspect. I even have my doubts about Ed25519; I personally only use it where a device has throughput problems with RSA. Cheers, R0b0t1