On 6/09/22 22:02, Olaf Meeuwissen wrote:
> Hi,
>
> Daniel Reurich writes:
>
>> Yes the key expired, and I probably noticed first by virtue of living in
>> the future compared to everyone else.
>>
>> We should be adding a new signing key each release for the next future
>> release, and ensuring it will endure for at least 2 future release.
>> This should be done immediately following a release.
>
> ACK, but predicting how long it will take for the next two releases to
> see the light of day is not exactly easy because Debian/Devuan release
> when ready.

I agree, so we err on the side of caution and plan for atleast 2 release
cycles that way there should always be a working key in every release,
but the old key carries through long enough if the release cycle time
suddenly doubles.
>
> How about uploading a new devuan-keyring package to stable-updates and
> unstable when the key's validity period has reached roughly 1/3 of its
> initial value? So if you start with a key that's valid for the next 3
> years, you would upload that new devuan-keyring package 2 years later.
> This is completely independent of the release cycle and should work if
> I'm not badly mistaken.

I'd been thinking 5 years expiry so it's not really about prediction at
all. I'm more concerned about making it a part of the standard release
cycle rather then letting it be forgotten about causing this current hiccup.

> 
> FTR, this idea is shamelessly stolen from the way cert-manager handles
> TLS certificates in Kubernetes clusters by default, be it that uses 90
> days for the certificate's validity period.
> 
>> This should be part of our "New Release - Devuan Devs guide to managing
>> the new release process." - if such a document should exist.  (If it
>> doesn't maybe we should create it.)
>>
>> Regards,
>>     Daniel
>>-- 

Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722