Devuan bug report logs - #705
Update failed due to an invalide signature

Full log

Message #30 received at 705@bugs.devuan.org (full text, mbox, reply):

Received: (at 705) by bugs.devuan.org; 6 Sep 2022 10:37:54 +0000
Return-Path: <daniel@centurion.net.nz>
Delivered-To: devuanbugs@dyne.org
Received: from mail.dyne.org [141.95.83.167]
	by doc.devuan.org with IMAP (fetchmail-6.4.16)
	for <debbugs@localhost> (single-drop); Tue, 06 Sep 2022 10:37:54 +0000 (UTC)
Received: from mbx.knossos.net.nz (mbx.knossos.net.nz [202.160.48.10])
	by mail.dyne.org (Postfix) with ESMTP id 984566618E1
	for <705@bugs.devuan.org>; Tue,  6 Sep 2022 12:36:26 +0200 (CEST)
Received: from [192.168.2.146] (crm.2serve.nz [202.160.51.126])
	(authenticated bits=0)
	by mbx.knossos.net.nz (8.14.4/8.14.4) with ESMTP id 286AaHEG029800
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Tue, 6 Sep 2022 22:36:19 +1200
Message-ID: <559636f8-8809-2346-870e-d8e65f369a00@centurion.net.nz>
Date: Tue, 6 Sep 2022 22:36:16 +1200
MIME-Version: 1.0
Content-Language: en-US
To: Olaf Meeuwissen <paddy-hack@member.fsf.org>,
        devuan developers internal list <devuan-dev@lists.dyne.org>
Cc: Klaus Ethgen <Klaus@ethgen.de>, 705@bugs.devuan.org
References: <YxWi7GN6UjFhvWaG@ikki.ethgen.ch>
 <handler.705.B.166236237917527.ack@bugs.devuan.org>
 <YxWrAZF+oHdmvQHa@ikki.ethgen.ch>
 <4aa6136d-7b31-7e05-ea2a-8e4c9b24ed37@centurion.net.nz>
 <874jxkvn0n.fsf@quark>
From: Daniel Reurich <daniel@centurion.net.nz>
Subject: Re: [devuan-dev] bug#705: Acknowledgement (Update failed due to an
 invalide signature)
In-Reply-To: <874jxkvn0n.fsf@quark>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------q0E4BLNxFjv0SyEBSWKsXiom"
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED
	autolearn=disabled version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.dyne.org

[Message part 1 (text/plain, inline)]

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

[OpenPGP_signature (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.