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

Package: amprolla; Maintainer for amprolla is Devuan Developers <devuan-dev@lists.dyne.org>;

Reported by: Klaus Ethgen <Klaus@ethgen.de>

Date: Mon, 5 Sep 2022 07:20:01 UTC

Severity: critical

Merged with 704

Done: Mark Hindley <mark@hindley.org.uk>

Full log


🔗 View this message in rfc822 format

X-Loop: owner@bugs.devuan.org
Subject: bug#705: [devuan-dev] bug#705: Acknowledgement (Update failed due to an invalide signature)
Reply-To: Daniel Reurich <daniel@centurion.net.nz>, 705@bugs.devuan.org
Resent-From: Daniel Reurich <daniel@centurion.net.nz>
Resent-To: devuan-bugs@lists.dyne.org
Resent-CC: devuan-dev@lists.dyne.org
X-Loop: owner@bugs.devuan.org
Resent-Date: Tue, 06 Sep 2022 10:38:02 +0000
Resent-Message-ID: <handler.705.B705.166246067414668@bugs.devuan.org>
Resent-Sender: owner@bugs.devuan.org
X-Devuan-PR-Message: followup 705
X-Devuan-PR-Package: devuan
X-Devuan-PR-Keywords: 
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> <YxWi7GN6UjFhvWaG@ikki.ethgen.ch>
Received: via spool by 705-submit@bugs.devuan.org id=B705.166246067414668
          (code B ref 705); Tue, 06 Sep 2022 10:38:02 +0000
Received: (at 705) by bugs.devuan.org; 6 Sep 2022 10:37:54 +0000
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
From: Daniel Reurich <daniel@centurion.net.nz>
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.


Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Devuan Bugs Owner <owner@bugs.devuan.org>.
Last modified: Sun Apr 28 19:32:40 2024;