Bug 9385 - all RPM since 13 march are released with an expired signature
Summary: all RPM since 13 march are released with an expired signature
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: release_blocker major
Target Milestone: ---
Assignee: Sysadmin Team
QA Contact:
URL:
Whiteboard:
Keywords:
: 9389 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-14 14:38 CET by Bit Twister
Modified: 2013-03-16 16:12 CET (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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
Note You need to log in before you can comment on or make changes to this bug.