On Sun, Jan 27, 2013 at 03:19:14PM +0530, Sudaraka Wijesinghe wrote:

error: libdbi: signature from "Thorsten T��pper <atsutane@freethoughts.de>" is unknown trust error: libdbi-drivers: signature from "Thorsten T��pper <atsutane@freethoughts.de>" is unknown trust error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded.

I already tried removing the keys and recreating them using pacman-key. And also cleared pacman cache so the the package is downloaded again.

Does this indicate tampering/file corruption or an expired key?

Should I file a bug report? (this is a community package)

Thanks.

Thorsten's gpg key expired a few days ago, but he has uploaded a new one. Run # pacman-key --refresh-keys to get his new key (and also any other keys that happen to be out of date. -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F

William Giokas <1007380@gmail.com> on Sun, 2013/01/27 15:56:

On Sun, Jan 27, 2013 at 03:19:14PM +0530, Sudaraka Wijesinghe wrote:

...

error: libdbi: signature from "Thorsten T��pper <atsutane@freethoughts.de>" is unknown trust error: libdbi-drivers: signature from "Thorsten T��pper <atsutane@freethoughts.de>" is unknown trust error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded.

I already tried removing the keys and recreating them using pacman-key. And also cleared pacman cache so the the package is downloaded again.

Does this indicate tampering/file corruption or an expired key?

Should I file a bug report? (this is a community package)

Thanks.

Thorsten's gpg key expired a few days ago, but he has uploaded a new one. Run

# pacman-key --refresh-keys

to get his new key (and also any other keys that happen to be out of date.

Running this from cron from time to time makes sense in my opinion. I've already added this on my systems some time ago, though this is not the default. Any objections adding this to pacman package? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

On Mon, 28 Jan 2013 15:56:37 +0100 Sébastien Luttringer <seblu@seblu.net> wrote:

Have an archlinux-keyring updated before key expiration is an elegant solution.

Cheers,

Indeed. Also, it was my mistake not to update the key before it expired and I have to apologize for that. By now there is a new archlinux-keyring package that contains the updated key. I'm sorry for all the trouble this has caused.

On Mon, Jan 28, 2013 at 04:09:54PM +0100, Kwpolska wrote:

On Mon, Jan 28, 2013 at 4:08 PM, Thorsten Töpper <atsutane@freethoughts.de> wrote:

...

On Mon, 28 Jan 2013 15:56:37 +0100 Sébastien Luttringer <seblu@seblu.net> wrote:

...

Have an archlinux-keyring updated before key expiration is an elegant solution.

Cheers,

Indeed.

Also, it was my mistake not to update the key before it expired and I have to apologize for that. By now there is a new archlinux-keyring package that contains the updated key.

I'm sorry for all the trouble this has caused.

Bonus question, why did the key even expire?

That's generally what happens when you put an expiration date on a GPG key and time passes up until the current time exceeds the expiration date.

[2013-01-28 23:36:48 -0300] Martín Cigorraga:

On Mon, Jan 28, 2013 at 6:05 PM, Dave Reisner <d@falconindy.com> wrote:

...

That's generally what happens when you put an expiration date on a GPG key and time passes up until the current time exceeds the expiration date.

http://www.youtube.com/watch?v=DRMBxnxWiNQ

Please. Dave's answer certainly misses the real question of why Thorsten would want an expiration date on his GPG key, but if that was what you meant to say just spare us the drama and say it. -- Gaetan

[2013-01-29 04:51:49 +0100] Karol Babioch:

Am 29.01.2013 04:37, schrieb Gaetan Bisson:

...

Dave's answer certainly misses the real question of why Thorsten would want an expiration date on his GPG key,

Because its good and common practice. There are several reasons for this, one of which is a compromise. When you got compromised and lose your revocation certificate, too, the key will expire at some point in time.

So instead of impersonating you for the rest of your life, the attacker who compromised your key can only do so for a whole year? Well, only a few hours generally suffice for them to cause terrible damage - that is certainly true with Arch's package signing infrastructure. Expiring keys trade ease-of-use for a fake sense of security, so better avoid them and actually secure your key and revocation certificates.

I'm not sure about GPG, but in case of X.509 it also helps to keep the certificate revocations lists (CRL) short, as certificates, which are expired anyway, don't have to be listed here explicitly.

In my opinion, that's a moot technical point which does not concern GPG. Cheers. -- Gaetan