[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    =?UTF-8?Q?Re:_[gentoo-dev]_[PATCH_v5_03/16]_glep-0063:_'Gentoo_subk?= =?UTF-8?Q?ey'_=e2=86=92_'Signi
From:       Joshua Kinard <kumba () gentoo ! org>
Date:       2018-07-26 2:49:07
Message-ID: 9892698c-4f53-f352-cebe-dabdd1c6577a () gentoo ! org
[Download RAW message or body]

On 7/25/2018 1:38 AM, Michał Górny wrote:
> W dniu śro, 25.07.2018 o godzinie 01∶28 -0400, użytkownik Joshua Kinard
> napisał:
>> On 7/8/2018 2:38 PM, Michał Górny wrote:
>>> 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 <k_f@gentoo.org>
>>> ---
>>>  glep-0063.rst | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/glep-0063.rst b/glep-0063.rst
>>> index 0773e3b..f02537d 100644
>>> --- a/glep-0063.rst
>>> +++ b/glep-0063.rst
>>> @@ -116,7 +116,7 @@ Recommendations
>>>  
>>>     a. Root key: 3 years maximum, expiry date renewed annually.
>>>  
>>> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
>>> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
>>>  
>>>  5. Create a revocation certificate & store it hardcopy offsite securely
>>>     (it's about ~300 bytes).
>>>
>>
>> I lost track of this due to other priorities, but picking through some of the
>> follow-up messages about the lead time on renewals and all, I don't have a
>> problem with that.  But why is the maximum of one year on subkey/signing key
>> expiration still here?
> 
> Because I've started with small changes, and the thing you're asking
> about is changed in a followup patch.  Please read the final text
> instead of wrongly assuming something from irrelevant change.

Yep, you're right.  Sorry about that!  I am fine with the specified timeframe
in the current iteration.


>>
>> I'm not seeing a lot of additional follow-up on that, but that is still too
>> short.  Two years is perfectly fine in this case.  I'd prefer three years
>> myself, but am willing to compromise for two.  I am not doing one year unless
>> someone drops some really convincing logic on me.  And no, scrawling "logic" on
>> the side of an anvil doesn't count.
>>
>> Does anyone know what the other projects require for their keys?  Without a
>> proper explanation of //why// one year needs to be the maximum, looking to what
>> other projects use seems sensible for guidance.
>>
>> I can't seem to find any specific guidance from Debian, but FreeBSD appears to
>> be fine with three years on their committer keys:
>>
>> """
>> A three year key lifespan is short enough to obsolete keys weakened by
>> advancing computer power, but long enough to reduce key management problems.
>> """
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys
>>

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

[prev in list] [next in list] [prev in thread] [next in thread]