[gentoo-portage-dev] [PATCH] Add python2 compatible coroutine support (bug 660426)

[Zac Medico]

For readability, it's desirable to make asynchronous code use
coroutines to avoid callbacks when possible. For python2 compatibility,
generators that yield Futures can be used to implement coroutines.

Add a compat_coroutine module which provides a @coroutine decorator
and a coroutine_return function that can be used to return a value
from a generator. The decorated function returns a Future which is
done when the generator is exhausted. Usage is very similar to asyncio
coroutine usage in python3.4 (see unit tests).

Bug: https://bugs.gentoo.org/660426
---
 .../tests/util/futures/test_compat_coroutine.py| 57 ++
 pym/portage/util/futures/compat_coroutine.py   | 90 ++
 2 files changed, 147 insertions(+)
 create mode 100644 pym/portage/tests/util/futures/test_compat_coroutine.py
 create mode 100644 pym/portage/util/futures/compat_coroutine.py

diff --git a/pym/portage/tests/util/futures/test_compat_coroutine.py 
b/pym/portage/tests/util/futures/test_compat_coroutine.py
new file mode 100644
index 00..4a1d931b6b
--- /dev/null
+++ b/pym/portage/tests/util/futures/test_compat_coroutine.py
@@ -0,0 +1,57 @@
+# Copyright 2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.util.futures import asyncio
+from portage.util.futures.compat_coroutine import (
+   coroutine,
+   coroutine_return,
+)
+from portage.tests import TestCase
+
+
+class CompatCoroutineTestCase(TestCase):
+
+   def test_returning_coroutine(self):
+   @coroutine
+   def returning_coroutine():
+   coroutine_return('success')
+   yield None
+
+   self.assertEqual('success',
+   
asyncio.get_event_loop().run_until_complete(returning_coroutine()))
+
+   def test_raising_coroutine(self):
+
+   class TestException(Exception):
+   pass
+
+   @coroutine
+   def raising_coroutine():
+   raise TestException('exception')
+   yield None
+
+   self.assertRaises(TestException,
+   asyncio.get_event_loop().run_until_complete, 
raising_coroutine())
+
+   def test_cancelled_coroutine(self):
+
+   @coroutine
+   def endlessly_sleeping_coroutine(loop=None):
+   loop = asyncio._wrap_loop(loop)
+   yield loop.create_future()
+
+   loop = asyncio.get_event_loop()
+   future = endlessly_sleeping_coroutine(loop=loop)
+   loop.call_soon(future.cancel)
+
+   self.assertRaises(asyncio.CancelledError,
+   loop.run_until_complete, future)
+
+   def test_sleeping_coroutine(self):
+   @coroutine
+   def sleeping_coroutine():
+   for i in range(3):
+   x = yield asyncio.sleep(0, result=i)
+   self.assertEqual(x, i)
+
+   
asyncio.get_event_loop().run_until_complete(sleeping_coroutine())
diff --git a/pym/portage/util/futures/compat_coroutine.py 
b/pym/portage/util/futures/compat_coroutine.py
new file mode 100644
index 00..eea0b2883e
--- /dev/null
+++ b/pym/portage/util/futures/compat_coroutine.py
@@ -0,0 +1,90 @@
+# Copyright 2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.util.futures import asyncio
+import functools
+
+
+def coroutine(generator_func):
+   """
+   A decorator for a generator function that behaves as coroutine function.
+   The generator should yield a Future instance in order to wait for it,
+   and the result becomes the result of the current yield-expression,
+   via the PEP 342 generator send() method.
+
+   The decorated function returns a Future which is done when the generator
+   is exhausted. The generator can return a value via the coroutine_return
+   function.
+   """
+   return functools.partial(_generator_future, generator_func)
+
+
+def coroutine_return(result=None):
+   """
+   Return a result from the current coroutine.
+   """
+   raise _CoroutineReturnValue(result)
+
+
+def _generator_future(generator_func, *args, **kwargs):
+   """
+   Call generator_func with the given arguments, and return a Future
+   that is done when the resulting generation is exhausted. If is a
+   keyword argument named 'loop' is given, then it is used instead of
+   the default event loop.
+   """
+   loop = asyncio._wrap_loop(kwargs.get('loop'))
+   result = loop.create_future()
+   _GeneratorTask(generator_func(*args, **kwargs), result, loop=loop)
+   return result
+
+
+class _CoroutineReturnValue(Exception):
+   def __init__(self, result):
+   self.result = result
+
+
+class _GeneratorTask(object):
+   

Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[R0b0t1]

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

Re: [gentoo-dev] rfc: killing mediawiki

[Kent Fredric]

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] rfc: killing mediawiki

[Jonas Stein]

>> 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] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Joshua Kinard]

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] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Kristian Fiskerstrand]

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

[Kristian Fiskerstrand]

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

[Joshua Kinard]

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 09/11] glep-0063: Make recommended expiration terms mandatory

[Joshua Kinard]

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 00/11] Major GLEP 63 update; full text

[Kristian Fiskerstrand]

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 00/11] Major GLEP 63 update; full text

[Ulrich Mueller]

> 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

[Kristian Fiskerstrand]

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

[Robin H. Johnson]

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 05/10] xdg.eclass: make EAPI 7 ready

[Marty E. Plummer]

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

[Michał Górny]

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 v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Michał Górny]

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

[Ulrich Mueller]

> 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

[Ulrich Mueller]

> 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

[Michał Górny]

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 

[gentoo-dev] [PATCH 13/13] glep-0063: Split out the signing subkey into a separation point

[Michał Górny]

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

[gentoo-dev] [PATCH 12/13] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Michał Górny]

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] Lastrites: app-crypt/gkeys-gen

[Brian Dolbec]

# 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 

Re: [gentoo-dev] rfc: killing mediawiki

[William Hubbs]

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

Re: [gentoo-dev] rfc: killing mediawiki

[William Hubbs]

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] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Matthew Thode]

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

[Brian Dolbec]

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

[Michał Górny]

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

[gentoo-dev] Package up for grabs: sys-apps/pacman

[Nils Freydank]

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_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

[Kristian Fiskerstrand]

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

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

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 

[gentoo-dev] [PATCH v2 11/11] glep-0063: Disallow using DSA keys

[Michał Górny]

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 10/11] glep-0063: Require renewal 2 weeks before expiration

[Michał Górny]

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 08/11] glep-0063: Stop recommending DSA subkeys

[Michał Górny]

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 09/11] glep-0063: Make recommended expiration terms mandatory

[Michał Górny]

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 07/11] glep-0063: Allow ECC, curve 25519 keys

[Michał Górny]

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 06/11] glep-0063: Change the recommended RSA key size to 2048 bits

[Michał Górny]

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 05/11] glep-0063: Explain minimal & recommended sections

[Michał Górny]

---
 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 04/11] glep-0063: Root key → primary key

[Michał Górny]

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 02/11] glep-0063: RSAv4 -> OpenPGP v4 key format

[Michał Górny]

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 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

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 01/11] glep-0063: Use 'OpenPGP' as appropriate

[Michał Górny]

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 00/11] Major GLEP 63 update

[Michał Górny]

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

Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys

[Kristian Fiskerstrand]

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

Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[Michał Górny]

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

[Kristian Fiskerstrand]

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

[Michał Górny]

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

[Kristian Fiskerstrand]

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] rfc: killing mediawiki

[Kent Fredric]

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

[gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys

[Michał Górny]

---
 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