Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys
> 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)? 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). Ulrich pgpJ4mpPSONpb.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
> 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. Ulrich pgpmCqp8kM_kf.pgp Description: PGP signature
Re: [gentoo-dev] rfc: killing mediawiki
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 pgpcwjyBR3Fd7.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: killing mediawiki
On Thu, 5 Jul 2018 12:44:42 -0500 William Hubbs wrote: > Have you even looked at gollum for example? it can support mw markdown. I've looked at it, but none of my reading of online material indicates whether it supports more than the existing media-wiki *syntax*. For instance, Gollum states support for macros, but definition of those macros requires writing ruby code, which is a far stretch from MediaWiki's "other wiki articles are your macros" Nothing I've read clarifies my confusion as to whether gollum actually supports all the *features* of MediaWiki, only seeming to indicate it supports syntax-mimicry. Which, if true, would fall into the category of "Not a suitable replacement" pgp1pVq15WwQf.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rfc: why are we still distributing the portage tree via rsync?
On Fri, 06 Jul 2018 01:55:32 +0200 Gerion Entrup wrote: > Would it possible to take the bare repo (< 600 MB) and only mount the latest > checkout (with fuse eg)? That would incur performance problems, because packed objects are stored as differences to other objects ( similar to how later pieces in a gzip stream are dependent on earlier pieces in the stream ). Subsequently, having a real checkout substantially improves performance. For a FUSE module to compete with this, it would need a lot of special mechanics, including keeping lots of memory reserved for state. So you might end up trading that additional 800mb disk space for 500mb-1.5gb of memory utilization. pgpuzvJLTft_g.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rfc: why are we still distributing the portage tree via rsync?
Am Donnerstag, 5. Juli 2018, 14:03:36 CEST schrieb Martin Vaeth: > Matt Turner wrote: > > The ebuild tree is 600MB with rsync and cannot fit on the partition > > with git. > > > > I'd be happy to switch if the space requirements were similar. > > If one git repacks every few syncs one needs currently about 800 MB. > > With additionally squashfs (zstd) (+ overlayfs) the full > archive size is currently <600 MB. > > In both cases, the temporary disk space is slightly more, of course. > For a 1GB reserved partition I'd use the partition for the temporary > mounting and store the archive somewhere else, but I think chances are > good that you also come through with only a git repack after > every sync. A difficulty might be the very first git sync. Would it possible to take the bare repo (< 600 MB) and only mount the latest checkout (with fuse eg)? Gerion
Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys
> 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. It would be great if a ECC user could sum up in a list where we still need some progress. -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH v3 12/12] 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 d41a2a0..33cbb67 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]_. @@ -77,11 +79,9 @@ not be used to commit. 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) + a. RSA, >=2048 bits (OpenPGP v4 key format or later only) - c. ECC curve 25519 + b. ECC curve 25519 4. Expiration date on key and all subkeys set to at most 2 years -- 2.18.0
[gentoo-dev] [PATCH v3 11/12] 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 0fdf5ed..d41a2a0 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -32,6 +32,10 @@ v2 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. + 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]_. @@ -81,7 +85,10 @@ not be used to commit. 4. Expiration date on key and all subkeys set to at most 2 years -5. Upload your key to the SKS keyserver rotation before usage! +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 --- -- 2.18.0
[gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory
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. --- glep-0063.rst | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 8c3dd1b..0fdf5ed 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-05 Post-History: 2013-11-10 @@ -27,6 +27,11 @@ 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. + 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,7 +79,7 @@ not be used to commit. c. ECC curve 25519 -4. Key expiry: 5 years maximum +4. Expiration date on key and all subkeys set to at most 2 years 5. Upload your key to the SKS keyserver rotation before usage! @@ -131,11 +136,7 @@ their primary key). 2. Primary key and the signing subkey are both of type RSA, 2048 bits (OpenPGP v4 key format or later) -3. Key expiry: - - a. Primary key: 3 years maximum, expiry date renewed annually. - - b. Signing subkey: 1 year maximum, expiry date renewed every 6 months. +3. Key expiration renewed annually 4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -- 2.18.0
[gentoo-dev] [PATCH v3 08/12] 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 60b68ca..f6f2959 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 == @@ -67,6 +69,8 @@ not be used to commit. 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! -- 2.18.0
[gentoo-dev] [PATCH v3 09/12] 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 | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index f6f2959..8c3dd1b 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 == @@ -125,24 +128,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) - -3. The signing subkey of EITHER: - - a. DSA 2048 bits exactly. - - b. RSA 2048 bits exactly. +2. Primary key and the signing subkey are 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. Signing 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 v3 07/12] 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 b995d8e..60b68ca 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-05 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 == @@ -112,15 +121,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: @@ -173,6 +180,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 v3 06/12] 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 2d30f68..b995d8e 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:: @@ -60,6 +64,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 v3 05/12] 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 | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 318717a..2d30f68 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -45,15 +45,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 --- @@ -105,7 +108,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 v3 04/12] 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 a56ae65..318717a 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. Primary key and signing subkey 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. Signing 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 v3 03/12] 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 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index 8e4f0d5..a56ae65 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-05 Post-History: 2013-11-10 Content-Type: text/x-rst --- @@ -115,7 +115,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 v3 02/12] 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 v3 01/12] 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 v3 00/12] GLEP 63 update
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:: 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
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > I don't really know the original rationale for this. > > The NIST standard says 1-3 years. If I were to guess, I'd say 1 year > was chosen for subkey because subkey expiring is a 'smaller' issue than > the whole key expiring, i.e. other users see the primary key as being > still valid. Quoting the NIST standard in this regard is a bit silly. It recommends that the total "cryptoperiod" (this is the total timeinterval a single key should be actively used) of a private key for the purpose of signing shall be 1 - 3 years. (The publickey for verification is unspecified) If we would follow this to the letter, we would all have to rotate (not extend) our pgp keys after 3 years. Can we just do something sensible here? I.e. requiring a key expiry of 2 years on any key (primary and subkeys)? Two years is a reasonable timeframe. Everyone with an air-gapped primary key can afford the 30 minutes to update signatures *every other* year. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu czw, 05.07.2018 o godzinie 13∶24 -0500, użytkownik William Hubbs napisał: > On Thu, Jul 05, 2018 at 03:36:09PM +0200, Michał Górny wrote: > > W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard > > napisał: > > > 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. > > > > > > > I don't really know the original rationale for this. > > > > The NIST standard says 1-3 years. If I were to guess, I'd say 1 year > > was chosen for subkey because subkey expiring is a 'smaller' issue than > > the whole key expiring, i.e. other users see the primary key as being > > still valid. > > > > I suppose the advantage of having disjoint expiration times is that if > > you forget about it, you'd learn the hard way that you need to renew it > > before the primary key expired. > > > > That said, I'm open to using a different recommendation, e.g. 2 years > > as in riseup [1]. I suppose having the same time for both primary key > > and subkeys would make the spec simpler, and many developers are > > mistaking expiration times (as specified now) anyway. > > > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years > > Can you link the nist standard? I'm curious about it because their > password standards are quite different.They no longer recommend forcing > password changes unless there is a breach. > I'm afraid that's PDF. Not sure if that will work for you: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf It's section 5.3.6: Cryptoperiod Recommendations for Specific Key Types. Quoting: | 1. Private signature key: | [...] | b. Cryptoperiod: Given the use of approved algorithms and key sizes, | and an expectation that the security of the key-storage and use | environment will increase as the sensitivity and/or criticality | of the processes for which the key provides integrity protection | increases, a maximum cryptoperiod of about one to three years is | recommended. The key shall be destroyed at the end of its | cryptoperiod. -- 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
W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc Schiffbauer napisał: > * Matthias Maier schrieb am 05.07.18 um 15:51 Uhr: > > > > On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > > > > > That said, I'm open to using a different recommendation, e.g. 2 years > > > as in riseup [1]. I suppose having the same time for both primary key > > > and subkeys would make the spec simpler, and many developers are > > > mistaking expiration times (as specified now) anyway. > > > > > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years > > > > Make it at most 2, 3, (or as it has been so far 5) years for both > > primary and subkeys. > > +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. -- 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 Thu, Jul 05, 2018 at 03:36:09PM +0200, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard > napisał: > > 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. > > > > I don't really know the original rationale for this. > > The NIST standard says 1-3 years. If I were to guess, I'd say 1 year > was chosen for subkey because subkey expiring is a 'smaller' issue than > the whole key expiring, i.e. other users see the primary key as being > still valid. > > I suppose the advantage of having disjoint expiration times is that if > you forget about it, you'd learn the hard way that you need to renew it > before the primary key expired. > > That said, I'm open to using a different recommendation, e.g. 2 years > as in riseup [1]. I suppose having the same time for both primary key > and subkeys would make the spec simpler, and many developers are > mistaking expiration times (as specified now) anyway. > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years Can you link the nist standard? I'm curious about it because their password standards are quite different.They no longer recommend forcing password changes unless there is a breach. Thanks, William signature.asc Description: Digital signature
[gentoo-portage-dev] [PATCH] rsync: quarantine data prior to verification (bug 660410)
Sync into a quarantine subdirectory, using the rsync --link-dest option
to create hardlinks to identical files in the previous snapshot of the
repository. If hardlinks are not supported, then show a warning message
and sync directly to the normal repository location.
If verification succeeds, then the quarantine subdirectory is synced
to the normal repository location, and the quarantine subdirectory
is deleted. If verification fails, then the quarantine directory is
preserved for purposes of analysis.
Even if verification happens to be disabled, the quarantine directory
is still useful for making the repository update more atomic, so that
it is less likely that normal repository location will be observed in
a partially synced state.
Bug: https://bugs.gentoo.org/660410
---
pym/portage/sync/modules/rsync/rsync.py | 101 +---
1 file changed, 93 insertions(+), 8 deletions(-)
diff --git a/pym/portage/sync/modules/rsync/rsync.py
b/pym/portage/sync/modules/rsync/rsync.py
index 382a1eaaef..9334c8a791 100644
--- a/pym/portage/sync/modules/rsync/rsync.py
+++ b/pym/portage/sync/modules/rsync/rsync.py
@@ -11,6 +11,7 @@ import functools
import io
import re
import random
+import subprocess
import tempfile
import portage
@@ -61,6 +62,68 @@ class RsyncSync(NewBase):
def __init__(self):
NewBase.__init__(self, "rsync", RSYNC_PACKAGE_ATOM)
+ def _select_download_dir(self):
+ '''
+ Select and return the download directory. It's desirable to be
able
+ to create shared hardlinks between the download directory to the
+ normal repository, and this is facilitated by making the
download
+ directory be a subdirectory of the normal repository location
+ (ensuring that no mountpoints are crossed). Shared hardlinks are
+ created by using the rsync --link-dest option.
+
+ Since the download is initially unverified, it is safest to save
+ it in a quarantine directory. The quarantine directory is also
+ useful for making the repository update more atomic, so that it
+ less likely that normal repository location will be observed in
+ a partially synced state.
+
+ This method tests if it is possible to create hardlinks in the
+ repository directory, and if that fails then it issues a warning
+ message and returns the normal repository location.
+ '''
+ with tempfile.NamedTemporaryFile(dir=self.repo.location,
+ prefix='.tmp', suffix='-portage-hardlink-test') as f:
+ hardlink = f.name + '-hardlink'
+ try:
+ os.link(f.name, hardlink)
+ except OSError as e:
+ writemsg_level("!!! Syncing directly to '%s'
because hardlink creation failed: %s\n" %
+ (self.repo.location, e),
level=logging.WARNING, noiselevel=-1)
+ return self.repo.location
+ finally:
+ try:
+ os.unlink(hardlink)
+ except OSError:
+ pass
+
+ return os.path.join(self.repo.location,
'.tmp-unverified-download-quarantine')
+
+ def _commit_download(self, download_dir):
+ '''
+ Commit changes from download_dir if it does not refer to the
+ normal repository location.
+ '''
+ exitcode = 0
+ if self.repo.location != download_dir:
+ rsynccommand = [self.bin_command] + self.rsync_opts +
self.extra_rsync_opts
+ rsynccommand.append('--exclude=/%s' %
os.path.basename(download_dir))
+ rsynccommand.append('%s/' % download_dir.rstrip('/'))
+ rsynccommand.append('%s/' % self.repo.location)
+ exitcode = subprocess.call(rsynccommand)
+ if exitcode == 0:
+ exitcode = self._remove_download(download_dir)
+
+ return exitcode
+
+ def _remove_download(self, download_dir):
+ """
+ Remove download_dir if it does not refer to the normal
repository
+ location.
+ """
+ exitcode = 0
+ if self.repo.location != download_dir:
+ exitcode = subprocess.call(['rm', '-rf', download_dir])
+ return exitcode
def update(self):
'''Internal update function which performs the transfer'''
@@ -97,6 +160,9 @@ class RsyncSync(NewBase):
self.extra_rsync_opts.extend(portage.util.shlex_split(
Re: [gentoo-dev] rfc: killing mediawiki
On Thu, Jul 05, 2018 at 01:26:51PM +1200, Kent Fredric wrote: > 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. That's the whole point of the discussion. Have you even looked at gollum for example? it can support mw markdown. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: killing mediawiki
On Thu, Jul 05, 2018 at 11:08:10AM +0200, Nils Freydank wrote: > Am Dienstag, 3. Juli 2018, 19:39:43 CEST schrieb William Hubbs: > > 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? > What about https://github.com/Git-Mediawiki/Git-Mediawiki? > "Gate between Git and Mediawiki" sounds as it would be the right extension > while mediawiki can be kept. 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. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Matthias Maier schrieb am 05.07.18 um 15:51 Uhr: > > On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > > > That said, I'm open to using a different recommendation, e.g. 2 years > > as in riseup [1]. I suppose having the same time for both primary key > > and subkeys would make the spec simpler, and many developers are > > mistaking expiration times (as specified now) anyway. > > > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years > > Make it at most 2, 3, (or as it has been so far 5) years for both > primary and subkeys. +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. -Marc -- 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 Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > That said, I'm open to using a different recommendation, e.g. 2 years > as in riseup [1]. I suppose having the same time for both primary key > and subkeys would make the spec simpler, and many developers are > mistaking expiration times (as specified now) anyway. > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years Make it at most 2, 3, (or as it has been so far 5) years for both primary and subkeys. Best, Matthias signature.asc 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 18∶48 -0400, użytkownik Joshua Kinard napisał: > 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. > I don't really know the original rationale for this. The NIST standard says 1-3 years. If I were to guess, I'd say 1 year was chosen for subkey because subkey expiring is a 'smaller' issue than the whole key expiring, i.e. other users see the primary key as being still valid. I suppose the advantage of having disjoint expiration times is that if you forget about it, you'd learn the hard way that you need to renew it before the primary key expired. That said, I'm open to using a different recommendation, e.g. 2 years as in riseup [1]. I suppose having the same time for both primary key and subkeys would make the spec simpler, and many developers are mistaking expiration times (as specified now) anyway. [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years -- 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∶43 +0200, użytkownik Kristian Fiskerstrand napisał: > 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 > We could say 'N year(s) + 2 weeks' but it would be kinda silly. Given that people are unhappy about one year anyway, let's defer this one for now. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: rfc: why are we still distributing the portage tree via rsync?
Matt Turner wrote: > The ebuild tree is 600MB with rsync and cannot fit on the partition > with git. > > I'd be happy to switch if the space requirements were similar. If one git repacks every few syncs one needs currently about 800 MB. With additionally squashfs (zstd) (+ overlayfs) the full archive size is currently <600 MB. In both cases, the temporary disk space is slightly more, of course. For a 1GB reserved partition I'd use the partition for the temporary mounting and store the archive somewhere else, but I think chances are good that you also come through with only a git repack after every sync. A difficulty might be the very first git sync.
[gentoo-portage-dev] [PATCH] GitSync: abort checkout for signature problem (bug 660372)
Fetch the upstream remote and use git merge to update the checkout
only after successful verification of the upstream head.
Suggested-by: Richard Freeman
Bug: https://bugs.gentoo.org/660372
---
pym/portage/sync/modules/git/git.py | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/pym/portage/sync/modules/git/git.py
b/pym/portage/sync/modules/git/git.py
index 160137a6d1..946846e1e1 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -109,6 +109,7 @@ class GitSync(NewBase):
if not self.has_bin:
return (1, False)
git_cmd_opts = ""
+ quiet = self.settings.get("PORTAGE_QUIET") == "1"
if self.repo.module_specific_options.get('sync-git-env'):
shlexed_env =
shlex_split(self.repo.module_specific_options['sync-git-env'])
env = dict((k, v) for k, _, v in
(assignment.partition('=') for assignment in shlexed_env) if k)
@@ -123,7 +124,21 @@ class GitSync(NewBase):
git_cmd_opts += " --quiet"
if
self.repo.module_specific_options.get('sync-git-pull-extra-opts'):
git_cmd_opts += " %s" %
self.repo.module_specific_options['sync-git-pull-extra-opts']
- git_cmd = "%s pull%s" % (self.bin_command, git_cmd_opts)
+
+ try:
+ remote_branch = portage._unicode_decode(
+ subprocess.check_output([self.bin_command,
'rev-parse',
+ '--abbrev-ref', '--symbolic-full-name',
'@{upstream}'],
+
cwd=portage._unicode_encode(self.repo.location))).rstrip('\n')
+ except subprocess.CalledProcessError as e:
+ msg = "!!! git rev-parse error in %s" %
self.repo.location
+ self.logger(self.xterm_titles, msg)
+ writemsg_level(msg + "\n", level=logging.ERROR,
noiselevel=-1)
+ return (e.returncode, False)
+
+ git_cmd = "%s fetch %s%s" % (self.bin_command,
+ remote_branch.partition('/')[0], git_cmd_opts)
+
writemsg_level(git_cmd + "\n")
rev_cmd = [self.bin_command, "rev-list", "--max-count=1",
"HEAD"]
@@ -133,20 +148,29 @@ class GitSync(NewBase):
exitcode = portage.process.spawn_bash("cd %s ; exec %s" % (
portage._shell_quote(self.repo.location),
git_cmd),
**self.spawn_kwargs)
+
+ if exitcode == os.EX_OK:
+ if not self.verify_head(revision='refs/remotes/%s^..' %
remote_branch):
+ return (1, False)
+
+ merge_cmd = [self.bin_command, 'merge',
'refs/remotes/%s' % remote_branch]
+ if quiet:
+ merge_cmd.append('--quiet')
+ exitcode = subprocess.call(merge_cmd,
+ cwd=portage._unicode_encode(self.repo.location))
+
if exitcode != os.EX_OK:
msg = "!!! git pull error in %s" % self.repo.location
self.logger(self.xterm_titles, msg)
writemsg_level(msg + "\n", level=logging.ERROR,
noiselevel=-1)
return (exitcode, False)
- if not self.verify_head():
- return (1, False)
current_rev = subprocess.check_output(rev_cmd,
cwd=portage._unicode_encode(self.repo.location))
return (os.EX_OK, current_rev != previous_rev)
- def verify_head(self):
+ def verify_head(self, revision='-1'):
if (self.repo.module_specific_options.get(
'sync-git-verify-commit-signature', 'false') !=
'true'):
return True
@@ -180,7 +204,7 @@ class GitSync(NewBase):
env = os.environ.copy()
env['GNUPGHOME'] = openpgp_env.home
- rev_cmd = [self.bin_command, "log",
"--pretty=format:%G?", "-1"]
+ rev_cmd = [self.bin_command, "log",
"--pretty=format:%G?", revision]
try:
status = (portage._unicode_decode(
subprocess.check_output(rev_cmd,
--
2.13.6
Re: [gentoo-dev] rfc: killing mediawiki
Am Dienstag, 3. Juli 2018, 19:39:43 CEST schrieb William Hubbs: > 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? What about https://github.com/Git-Mediawiki/Git-Mediawiki? "Gate between Git and Mediawiki" sounds as it would be the right extension while mediawiki can be kept. Best Regards Nils Freydank signature.asc Description: This is a digitally signed message part.
