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

critical

[Message part 1 (text/plain, inline)]
Package: devuan
Severity: critical

Today the update failed with the following error:
   Holen:13 http://deb.devuan.org/merged ceres InRelease [33,9 kB]
   Fehl:13 http://deb.devuan.org/merged ceres InRelease
     Die folgenden Signaturen waren ungültig: EXPKEYSIG BB23C00C61FC752C Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>
   ...
   W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: http://deb.devuan.org/merged ceres InRelease: Die folgenden Signaturen waren ungültig: EXPKEYSIG BB23C00C61FC752C Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>
   W: Fehlschlag beim Holen von http://deb.devuan.org/merged/dists/ceres/InRelease Die folgenden Signaturen waren ungültig: EXPKEYSIG BB23C00C61FC752C Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>

So, the whole update is broken!

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 5 (daedalus/ceres)
Release:	5
Codename:	daedalus ceres
Architecture: x86_64

Kernel: Linux 5.16.17 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Gruß
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Hi,

The reason seems to be that the key is expired.

The mitigation might be difficult. But you might have the way to do so.
Just sign the repository with the key
72E3CB773315DFA2E464743D94532124541922FB instead of
E032601B7CA10BC3EA53FA81BB23C00C61FC752C.

72E3CB773315DFA2E464743D94532124541922FB is in
/etc/apt/trusted.gpg.d/devuan-keyring-2016-archive.gpg and never expire.

After some months, just create a new key which never expire or expire
far in the future and use that for the repository.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus@Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
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.

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

On 5/09/22 19:53, Klaus Ethgen wrote:
> Hi,
> 
> The reason seems to be that the key is expired.
> 
> The mitigation might be difficult. But you might have the way to do so.
> Just sign the repository with the key
> 72E3CB773315DFA2E464743D94532124541922FB instead of
> E032601B7CA10BC3EA53FA81BB23C00C61FC752C.
> 
> 72E3CB773315DFA2E464743D94532124541922FB is in
> /etc/apt/trusted.gpg.d/devuan-keyring-2016-archive.gpg and never expire.
> 
> After some months, just create a new key which never expire or expire
> far in the future and use that for the repository.
> 
> Regards
>     Klaus
> 
> 
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev

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

[OpenPGP_signature (application/pgp-signature, attachment)]
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.

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.

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
>
> On 5/09/22 19:53, Klaus Ethgen wrote:
>> Hi,
>>
>> The reason seems to be that the key is expired.
>>
>> The mitigation might be difficult. But you might have the way to do so.
>> Just sign the repository with the key
>> 72E3CB773315DFA2E464743D94532124541922FB instead of
>> E032601B7CA10BC3EA53FA81BB23C00C61FC752C.
>>
>> 72E3CB773315DFA2E464743D94532124541922FB is in
>> /etc/apt/trusted.gpg.d/devuan-keyring-2016-archive.gpg and never expire.
>>
>> After some months, just create a new key which never expire or expire
>> far in the future and use that for the repository.
>>
>> Regards
>>     Klaus
>>
>>
>> _______________________________________________
>> devuan-dev internal mailing list
>> devuan-dev@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev

[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)]
Control: reassign -1 amprolla
Control: merge -1 704

Klaus,

On Mon, Sep 05, 2022 at 08:19:08AM +0100, Klaus Ethgen wrote:
> Package: devuan
> Severity: critical
> 
> Today the update failed with the following error:
>    Holen:13 http://deb.devuan.org/merged ceres InRelease [33,9 kB]
>    Fehl:13 http://deb.devuan.org/merged ceres InRelease
>      Die folgenden Signaturen waren ungültig: EXPKEYSIG BB23C00C61FC752C
>    Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org

Thanks. The key used by amprolla has now been changed and upgrades are working
normally again.

Thanks.

Mark

On Fri, Sep 09, 2022 at 06:05:38PM +0100, Mark Hindley wrote:
> Thanks. The key used by amprolla has now been changed and upgrades are working
> normally again.

Closing as resolved.

Thanks

Mark

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

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

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