LinuxQuestions.org - Slackware Official GPG-KEY Expiration

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware Official GPG-KEY Expiration (https://www.linuxquestions.org/questions/slackware-14/slackware-official-gpg-key-expiration-4175736310/)

Slackware Official GPG-KEY Expiration

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? :eek:

Quote:

Originally Posted by dogemeister (Post 6497653)

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]

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

Quote:

Originally Posted by marav (Post 6497718)

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

Quote:

Originally Posted by henca (Post 6497739)

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

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 ;-(

Quote:

Originally Posted by rsts (Post 6498014)

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

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

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.

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.