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
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,
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
>> 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
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
>>>
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
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
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.
>
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.
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
> 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
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
>>>
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
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
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
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
> 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
> 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
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
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
---
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
# 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
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
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
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:
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
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
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
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
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
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:
>>
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
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
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
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
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
---
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
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
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
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
---
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
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
+++
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 ++--
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
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
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)
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
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
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
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
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
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
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
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
---
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
55 matches
Mail list logo
