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


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

Received: (at 705) by bugs.devuan.org; 10 Sep 2022 05:31:40 +0000
Return-Path: <olaf@ueda.ne.jp>
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); Sat, 10 Sep 2022 05:31:40 +0000 (UTC)
Received: from mo-sw.mose-mail.jp (mo-sw1801-0.mose-mail.jp [202.238.237.3])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by mail.dyne.org (Postfix) with ESMTPS id 64DDB661844
	for <705@bugs.devuan.org>; Sat, 10 Sep 2022 07:30:57 +0200 (CEST)
Received: by mo-sw.mose-mail.jp (mose-mo-sw1801) id 28A5UqBQ008801; Sat, 10 Sep 2022 14:30:53 +0900
Received: from quark (localhost [127.0.0.1])
	by mbox.mose-mail.jp (mose-mbox1801) id 28A5UloC032536
	for <705@bugs.devuan.org>; Sat, 10 Sep 2022 14:30:49 +0900
Received: from olaf (uid 1000)
	(envelope-from olaf@ueda.ne.jp)
	id 30603b
	by quark (DragonFly Mail Agent v0.13);
	Sat, 10 Sep 2022 14:30:47 +0900
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>
 <559636f8-8809-2346-870e-d8e65f369a00@centurion.net.nz>
From: Olaf Meeuwissen <paddy-hack@member.fsf.org>
To: Daniel Reurich <daniel@centurion.net.nz>
Cc: devuan developers internal list <devuan-dev@lists.dyne.org>,
        Klaus Ethgen <Klaus@ethgen.de>, 705@bugs.devuan.org
Subject: Re: [devuan-dev] bug#705: Acknowledgement (Update failed due to an
 invalide signature)
In-reply-to: <559636f8-8809-2346-870e-d8e65f369a00@centurion.net.nz>
Date: Sat, 10 Sep 2022 14:30:47 +0900
Message-ID: <87bkrn94oo.fsf@quark>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=0.2 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=disabled
	version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.dyne.org
Hi,

Daniel Reurich writes:

> 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.

Which is why I suggested putting key renewal on a fixed schedule.  With
5 years (60 months), you'd put out a new key 40 months later.  You could
even put it, or at least a reminder to do so, in a cron job ;-)

>> 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.)

--
Olaf Meeuwissen

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: Mon Apr 29 06:10:20 2024;