Bug 9385

Summary:	all RPM since 13 march are released with an expired signature
Product:	Mageia	Reporter:	Bit Twister <bittwister2>
Component:	Release (media or process)	Assignee:	Sysadmin Team <sysadmin-bugs>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	release_blocker	CC:	cooker, matali, sysadmin-bugs, wilcal.int
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Bit Twister 2013-03-14 14:38:17 CET

Description of problem:

seems all rpms are being released with no signatures

Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. Seen complaints about kde rpms in alt.os.linux.mageia
2. just updated privoxy and ekiga and all 4 rpms have the problem.
3.


Reproducible: 

Steps to Reproduce:

Comment 1 Manuel Hiebel 2013-03-14 16:23:56 CET

*** Bug 9389 has been marked as a duplicate of this bug. ***

CC: (none) => matali

Manuel Hiebel 2013-03-14 16:26:22 CET

Priority: Normal => release_blocker
Assignee: bugsquad => sysadmin-bugs

Comment 2 Manuel Hiebel 2013-03-14 16:30:08 CET

on irc, mageia-dev

15:26 < pterjan> -rw------- 1 signbot signbot 2439 Mar 13  2012 secring.gpg
15:26 < pterjan> I guess the key expired like it had done last year
15:27 < pterjan> sec   4096R/80420F66 2011-02-07 [expires: 2013-03-13]
15:28 < pterjan> pub  4096R/80420F66  created: 2011-02-07  expires: 2014-03-14  usage: SCEA
15:28 < pterjan> we need to sign the packages that went through since yesterday

Summary: 3_b3: seems all rpms are being released with no signatures => all RPM since 13 march are released with an expired signature

Comment 3 Bit Twister 2013-03-14 17:06:29 CET

(In reply to Manuel Hiebel from comment #2)

> 15:26 < pterjan> I guess the key expired like it had done last year

Every time I see a domain registration or key expired problem, I wonder why a system admin has not created a nag file generator cron job to create a whatever.nag file and added a .nag file check in /etc/cron.daily which mails the whatever.nag to whoever needs to manage the item(s) in the nag file.

I have yearly, monthly, weekly scripts which create nag files.
The daily nag check script looks for *.nag, pulls the first 2 lines from the file which has _subject="whatever" followed by _to="whoever1,whoever2,.." and does a
mail -s $_s $_to < $_nag_fn

Once whoever has completed the nag, s/he deletes the nag file.

Comment 4 Johnny A. Solbu 2013-03-14 17:40:48 CET

What I can't figure out is why packages are allowed to be pushed unsigned (yes, it's automatic, but that's beside the point). The fact that the sign proccess fails should fail the build system upload.

CC: (none) => johnny

William Kenney 2013-03-15 06:14:25 CET

CC: (none) => wilcal.int

Comment 5 Manuel Hiebel 2013-03-16 16:12:56 CET

should be now fixed

Status: NEW => RESOLVED
Resolution: (none) => FIXED