On Fri, 06 Jul 2018 08:18:32 +0200
Michał Górny wrote:
> W dniu pią, 06.07.2018 o godzinie 06∶08 +, użytkownik Robin H.
> Johnson napisał:
> > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
> > > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:
> > > > Replace the disjoi
On Fri, 06 Jul 2018 08:51:12 +0200
Michał Górny wrote:
> W dniu pią, 06.07.2018 o godzinie 06∶28 +, użytkownik Robin H.
> Johnson napisał:
> > On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:
> > > > option a)
> > > > 2 years + N:
> > > > 2 weeks <= N <= 3 months.
> > > >
> >
W dniu pią, 06.07.2018 o godzinie 06∶36 +, użytkownik Robin H.
Johnson napisał:
> On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> > Here's third version of the patches. I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-co
I disagree with adding this as a requirement.
Services should explicitly fail to work with expired GPG keys, key
renewal times should be at the key owner's descretion.
This should still be a recommendation that guarantees the key owner to
continue work without interruption.
Thanks,
Manuel
On 04
On 07/06/2018 07:49 AM, Ulrich Mueller wrote:
>> On Thu, 5 Jul 2018, Jonas Stein wrote:
>
>>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>>
>>> + c. ECC curve 25519
>>> +
>>> 4. Key expiry: 5 years maximum
>>> 5. Upload your key to the SKS keyserver rotation before usage!
>
W dniu pią, 06.07.2018 o godzinie 10∶11 +0200, użytkownik Manuel Rüger
napisał:
> I disagree with adding this as a requirement.
>
> Services should explicitly fail to work with expired GPG keys, key
> renewal times should be at the key owner's descretion.
> This should still be a recommendation th
Hi,
as I want to keep my work on Gentoo focussed, the following packages are
up for grabs as I don't use them:
app-admin/certmgr
app-emulation/hyperd
app-emulation/runv
dev-haskell/pgp-wordlist
dev-haskell/parser-combinators
dev-haskell/prettyprinter
dev-libs/onigmo
dev-python/grafanalib
dev-util
* Michał Górny schrieb am 05.07.18 um 20:25 Uhr:
> W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
> Schiffbauer napisał:
> > +1 for 5 years or at least 3.
> >
> > Having to renew/edit the key each year seems crazy to me.
> >
> > I have my primary key offline only, so renewing/edit
W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc
Schiffbauer napisał:
> * Michał Górny schrieb am 05.07.18 um 20:25 Uhr:
> > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
> > Schiffbauer napisał:
> > > +1 for 5 years or at least 3.
> > >
> > > Having to renew/edit th
* Michał Górny schrieb am 06.07.18 um 11:33 Uhr:
> W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc
> Schiffbauer napisał:
> > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr:
> > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
> > > Schiffbauer napisał:
> > > > +1 fo
On 07/05/2018 05:37 PM, Marc Schiffbauer wrote:
> I have my primary key offline only, so renewing/editing it is a much
> more time consuming matter than if I had my primary key always with me
> which I consider a bad idea because you do not need to.
But is it sufficiently time-consuming / diffic
> On Fri, 6 Jul 2018, Marc Schiffbauer wrote:
> * Michał Górny schrieb am 06.07.18 um 11:33 Uhr:
>> If you don't see it for 5 years, how can you be sure that it is
>> even still there?
> Are you serious? Who tells you that I do not check from time to
> time?
> I am sure there will always be
W dniu pią, 06.07.2018 o godzinie 13∶34 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 6 Jul 2018, Marc Schiffbauer wrote:
> > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr:
> > > If you don't see it for 5 years, how can you be sure that it is
> > > even still there?
> > Are you se
On 07/06/2018 01:34 PM, Ulrich Mueller wrote:
> Note that the revocation certificate is still listed under
> recommendations only, so devs need not create one. Making this a
> requirement would be a real improvement, IMHO.
From a Gentoo perspective, we can "revoke" it by deleting it from LDAP
and
On 06-07-2018 13:34:21 +0200, Ulrich Mueller wrote:
> - Make creation of a revocation certificate (and storing it in a place
> separate from the key) mandatory.
What does this really achieve? Or require? Am I supposed to buy or
hire a vault now? -- I'm assuming the word "safe" is missing fro
* Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr:
> On 07/05/2018 05:37 PM, Marc Schiffbauer wrote:
> > I have my primary key offline only, so renewing/editing it is a much
> > more time consuming matter than if I had my primary key always with me
> > which I consider a bad idea because y
W dniu pią, 06.07.2018 o godzinie 16∶21 +0200, użytkownik Marc
Schiffbauer napisał:
> * Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr:
> > On 07/05/2018 05:37 PM, Marc Schiffbauer wrote:
> > > I have my primary key offline only, so renewing/editing it is a much
> > > more time consuming m
On Fri, Jul 06, 2018 at 12:34:33PM +1200, Kent Fredric wrote:
> On Thu, 5 Jul 2018 12:32:20 -0500
> William Hubbs wrote:
>
> > I looked at this first, and it is very hard on the server.
> > Every pull or clone you do to update things works like an initial clone,
> > so it takes pretty massive res
> On Fri, 6 Jul 2018, Kent Fredric wrote:
> On Thu, 5 Jul 2018 12:32:20 -0500
> William Hubbs wrote:
>> I looked at this first, and it is very hard on the server.
>> Every pull or clone you do to update things works like an initial
>> clone, so it takes pretty massive resources.
> Surely, t
>> > 4. Expiration date on key and all subkeys set to at most 2 years
>>
>> -at most 2 years.
>> +at most 2 years from generation or refresh of expiry.
>
>Now, this won't really work because it's self-propagating date. You're
>soon going to see keys with 10 years to expiration because if you
>upd
> On Jul 5, 2018, at 4:53 PM, Michał Górny wrote:
>
> Hi,
>
> Here's third version of the patches. I've incorporated the feedback
> so far and reordered the patches (again) to restore their
> degree-of-compatibility order. The full text is included below.
>
>
> Michał Górny (12):
> glep-
W dniu pią, 06.07.2018 o godzinie 06∶36 +, użytkownik Robin H.
Johnson napisał:
> On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> > Here's third version of the patches. I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-co
W dniu pią, 06.07.2018 o godzinie 21∶26 -0400, użytkownik Richard Yao
napisał:
> > On Jul 5, 2018, at 4:53 PM, Michał Górny wrote:
> >
> > Hi,
> >
> > Here's third version of the patches. I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-
W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the requir
Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP.
G[nu]PG has been left where the text clearly refers to the specific
implementation of OpenPGP rather than the standard itself.
---
glep-0063.rst | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
Hi,
Here's the next iteration of the GLEP, integrating even more suggestions
from developers. Full text below.
Also, please do not reply to previous versions, as this is making
the discussion really hard to follow.
--
Best regards,
Michał Górny
Michał Górny (14):
glep-0063: Use 'OpenPGP' as
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
Replace the 'Gentoo subkey' term that might wrongly suggest that
the developers are expected to create an additional, dedicated subkey
for Gentoo.
Suggested-by: Kristian Fiskerstrand
---
glep-0063.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glep-0063.rst b/glep-0063.r
Replace the custom term 'root key' with much more common 'primary key'.
This is also the term used in GnuPG output.
---
glep-0063.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index 6be2555..940612c 100644
--- a/glep-0063.rst
+++ b/gl
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
---
glep-0063.rst | 8
1 file changed, 8 insertions(+)
diff --git a/glep-0063.rst b/glep-0063.rst
index 05e5e9d..a93e6ac 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -41,6 +41,10 @@ Specifications for OpenPGP keys
Bare minimum requirements
-
+This section
Change the recommended key size recommendation for RSA from 4096 bits
to 2048 bits. Use of larger keys is unjustified due to negligible gain
in security, and recommending RSA-4096 unnecessarily resulted
in developers replacing their RSA-2048 keys for no good reason.
---
glep-0063.rst | 20 +++
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 inserti
There is really no technical reason to use DSA these days, and we should
focus on having a single recommendation. DSA keys are still permitted
via 'minimal' requirements.
---
glep-0063.rst | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/glep-0063.rst b/glep
Replace the disjoint 'minimum' and 'recommendation' for expiration with
a single requirement. Make it 2.5 years with recommended annual renewal
to a fixed day of the year (2 years + some grace time for renewal).
Also, remove disjoint expiration recommendation for the primary key
and subkeys since
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 7bfbaa6..9ae9c74 100644
--- a/glep-006
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
ind
Requested-by: Robin H. Johnson
---
glep-0063.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index d4fd953..0792a5c 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -39,6 +39,9 @@ v2
The usage of DSA keys has been disallowed.
+
Requested-by: Richard Yao
---
glep-0063.rst | 54 +++
1 file changed, 7 insertions(+), 47 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index 0792a5c..b20af61 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -42,6 +42,9 @@ v2
The ``gp
39 matches
Mail list logo
