Slackware 14.0 GPG-KEY
 

I´m happy we are almost there for a new version, but...

Wouldn't it be better if we had a renewed/new GPG-KEY to sign Slackware 14.0 packages?

** The current GPG-KEY is from 2003 and will expire on 21st december 2012 **

I know that many people thinks the world is gonna end around this time, but... I'm pretty sure Slackware is going to survive this impending doom, so...

Of course Slackware will survive the apocalypse, as will all slackers. Bob will protect us, and we will party on.

Somewhat related to that end-of-the-world thing... Slackware 14 will have an easter egg which only becomes visible if you install Slackware 14 on 21 december, 2012...

Eric

What? Sends a signal via the intertubeswebnet thingy to detonate the entire world's nuclear arsenal? That will be worth seeing. Can't wait. :D

Updated my journal, I'll definitely try that.

It reminds me one fortune cookie: "The world will end in 5 minutes. Please log out." It would be nice to hack fortunes to schedule that one for December 21 :)

I have to remember to try it.

from man slackpkg
So, is that true? or in december we must re-run slackpkg update gpg?

Zerouno,
All digital certificates expire after a certain date. This is because the technology to pose security risks to them can improve a lot between "computer generations".
The current GPG-KEY used by Slackware was issued on february, 2003. That one will expire on 21 december this year. This can be verified using the following command in a bash prompt: gpg --list-keys.

I made a "time change" test in a virtual machine with slack 13.37 and tried to verify a patch signature. It was ok, with return code
0 but also displayed a note saying "This key has expired!".

The question is: will Slackware-14 release a new GPG-KEY, so that all packages are signed with that "future-proof" certificate or will we stick with the current one?
Sticking with a 9 year old key a few months from expiration is at least strange for such a traditional secure distro, IMHO.

But I'm pretty sure Pat will answer us very soon :-)

The patches released in 2013 for slackware 13.37, which gpg-key will use?

Good question!

If the GPG-KEY remains the same, after december 21st, it'll be impossible to sign anything with it. But it will be still possible to verify the old signatures.
I'm not a gpg especialist, but I'm sure there's a decent solution to that problem, maybe using subkeys.

re-sign all old-packages with a new gpg-key :-)




Slackware 8.1 packages are marked in the year 2002. The key presents on the repository is marked 2003.
Which key was used to sign, and when?

Some patch are marked in 2002 and some patch 2012. Are they signed with the same key?

Fortunately slackware 8.1 is End-Of-Life, so it will not soffer the Maya-bug :-)



Edit:
On the original cd of slackware 8.1 (that is downloadable) there is no gpg-key, and packages was not signed.
This means that the original packages was signed in future.

Well. This means that the 13.37 and all not EOL slackware will must be re-signed with a new key.

If a GPG key's expiry date is updated, then files which were signed with the old version of the GPG key will still validate OK.
I'll let you in on a secret:
Eric

Thank you Pat and Eric!
I´ve just noticed Slackware 14.0 RC4 included the updated GPG-KEY.

So...
Maya BUG: Bye, bye!
Year-2038 bug: We´ll squash you at the right moment ;-D

Aak! I don't have access to my laptop today to reinstall Slackware 14.0! I won't see the Easter Egg! 'Tis the end of the world! :'(
I'm going to hazard a guess and say that the Easter Egg is a Mayan themed Lilo boot screen... even though I dreamt (can you believe it!) a while ago that the first boot would flash ASCII keys (yes, the ones that open doors) in place of the ASCII... things that appear during first boot. But I'm probably incorrect on both fronts. Has anyone seen the Easter Egg?

mmm..

May be...
But may NOT :D


tomorrow change date to your computer and reinstall :D

I installed Slackware 14 today but I did not notice the Easter Egg.
OK what am I missing?

The Easter egg is that the Mayan LILO bootsplash will be installed...
Eric

Of course, I was right. As if I could ever be wrong... although my dreams seem prone to error... :D
Unfortunately I tried changing the date and installing, but to no avail. Looking at the code for liloconfig, I get the impression it's because I use Slackware64. Or maybe Bob got annoyed at me for trying to cheat. Anyway, I decided to track down the picture on the Slackware64 DVD and force the issue. 'Tis a pretty Lilo splash! :)

But slackpkg automatically does not refresh the key:

Oh, but it does!
However, the Slackware GPG key has only been updated in the Slackware 14.0 tree. You pointed slackpkg to a Slackware 13.37 mirror which still has the old key.

Eric

who have a slackware 13.37 server point to old key to install patches.


No, slackpkg does not update the key.

slackpkg verify succesfully the package integrity, it's true.
Seeing the code:
slackpkg does not show any warning becouse '2>/dev/null' is present.
Removing it slackpkg show the warning.
It's not a fatal, but demonstrates that slackpkg does not refresh the key!


Also,

Some unofficial tool as slapt-get refuse to accept the expired key:
Yes, is *unofficial* tool, so it's not real problem.

zerouno, let me explain again what I meant to say.

The command "slackpkg update gpg" will regresh the Slackware GPG key. It will download the GPG-KEY file from the mirror you have configured, for the Slackware release which you have configured. If that GPG-KEY file contains an expired key (which is the case with all Slackware releases before 14.0) then slackpkg will happily "refresh" the GPG key with that same expired key. Slackpkg does not check for expiration of the key!

Your (and mine) idea of "refreshing" is refreshing a key using a keyserver. This is not what "slackpkg update gpg" does.

I have asked Pat Volkerding to update the GPG-KEY file on all Slackware mirror releases for 13.37 and earlier, let's wait and see if he does that.

The need to remove that "2>/dev/null" is arguable. If the key verification fails, this function will return a "0" to the calling routine. This return code is checked and you will get a GPG verification error on your screen. I agree that you will not see the reason for the failure because the key expiration message is filtered out by that "2>/dev/null" redirection.

Eric

Has anyone installed on 21 december 2012? What was the easter egg?

see post #17

Thanks, I missed that post.