Slackware Official GPG-KEY Expiration

dogemeister · 04-22-2024, 06:31 AM

Not sure how many of you have looked at the official Slackware GPG-KEY, and maybe I'm late to the party noticing this, but it expires on a rather peculiar date.

Code:

security@slackware.com public key

pub   1024D/40102233 2003-02-26 [expires: 2038-01-19]
uid                  Slackware Linux Project <security@slackware.com>
sub   1024g/4E523569 2003-02-26 [expires: 2038-01-19]

Just thought this would be a funny mention for anyone who hadn't noticed.

Or perhaps rather than being a funny reference to the problem, it is some mitigation for or manifestation of said problem?

marav · 04-22-2024, 12:07 PM

Quote:

Originally Posted by dogemeister

Not sure how many of you have looked at the official Slackware GPG-KEY, and maybe I'm late to the party noticing this, but it expires on a rather peculiar date.

Code:

security@slackware.com public key

pub   1024D/40102233 2003-02-26 [expires: 2038-01-19]
uid                  Slackware Linux Project <security@slackware.com>
sub   1024g/4E523569 2003-02-26 [expires: 2038-01-19]

Just thought this would be a funny mention for anyone who hadn't noticed.

Or perhaps rather than being a funny reference to the problem, it is some mitigation for or manifestation of said problem?

I doubt there will still be people with 32-bit OS in 2038
If not, too bad for them

henca · 04-22-2024, 01:01 PM

Quote:

Originally Posted by marav

I doubt there will still be people with 32-bit OS in 2038
If not, too bad for them

Unfortunately, even with a 64 bit operating system, you might still have applications, databases and file systems which stores time stamps as 32 bit integers.

It is said that gpg is one of those applications which will fail if expiration date is set after year 2038. Another problematic software is utmp/wtmp which stores time stamps in 32 bit fields.

regards Henrik

marav · 04-22-2024, 01:14 PM

Quote:

Originally Posted by henca

It is said that gpg is one of those applications which will fail if expiration date is set after year 2038.

Fixed since 2.4.4

rsts · 04-24-2024, 01:13 AM

The problem isn't the expiration date or 32-bits. The problem is that the preferred signing algorithm for that key is SHA1. SHA1 is considered broken since 2017, but the slackware-security mailing list keeps using it to sign e-mail announcements. One of the consequences is that Thunderbird will mark the message with "Invalid message signature".

Code:

$ gpg2 --edit-key security@slackware.com
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  dsa1024/6A4463C040102233
     created: 2003-02-26  expires: 2038-01-19  usage: SCA 
     trust: unknown       validity: full
sub  elg1024/768737F94E523569
     created: 2003-02-26  expires: 2038-01-19  usage: ER  
[  full  ] (1). Slackware Linux Project <security@slackware.com>

gpg> showpref
[  full  ] (1). Slackware Linux Project <security@slackware.com>
     Cipher: AES, CAST5, 3DES
     AEAD: 
     Digest: SHA1, RIPEMD160
     Compression: ZLIB, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

Note that the preferred algorithm for signing can be changed for the key. I.e. it does not have to be replaced with a new key.

I wish I could somehow convey this to the responsible person(s), but until now I was not successful with that ;-(

volkerdi · 04-24-2024, 12:30 PM

Quote:

Originally Posted by rsts

The problem isn't the expiration date or 32-bits. The problem is that the preferred signing algorithm for that key is SHA1. SHA1 is considered broken since 2017, but the slackware-security mailing list keeps using it to sign e-mail announcements. One of the consequences is that Thunderbird will mark the message with "Invalid message signature".

Code:

$ gpg2 --edit-key security@slackware.com
gpg (GnuPG) 2.4.4; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  dsa1024/6A4463C040102233
     created: 2003-02-26  expires: 2038-01-19  usage: SCA 
     trust: unknown       validity: full
sub  elg1024/768737F94E523569
     created: 2003-02-26  expires: 2038-01-19  usage: ER  
[  full  ] (1). Slackware Linux Project <security@slackware.com>

gpg> showpref
[  full  ] (1). Slackware Linux Project <security@slackware.com>
     Cipher: AES, CAST5, 3DES
     AEAD: 
     Digest: SHA1, RIPEMD160
     Compression: ZLIB, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

Note that the preferred algorithm for signing can be changed for the key. I.e. it does not have to be replaced with a new key.

I wish I could somehow convey this to the responsible person(s), but until now I was not successful with that ;-(

I'll look into that, but if it's so broken then sign something with my key.

rsts · 04-24-2024, 01:11 PM

Whoa, thank you for responding, sir!

Quote:

if it's so broken then sign something with my key.

There were times when I could fake the From field in an e-mail. Probably not any longer ;-)
But that does not mean, there aren't any people out there who could. We talk about the main signing key for the distro.

rkomar · 04-24-2024, 01:38 PM

Isn't the issue with being able to duplicate the SHA1 digest for a modified object? That is, change the object and add some extra bytes to produce the same digest so that the signature still applies. That would be easier for SHA1 than another algorithm that produces more output bytes.