Bug 1043276 - release key N should be signed by release key N-1
Summary: release key N should be signed by release key N-1
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: sigul
Version: rawhide
Hardware: All
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-15 15:55 UTC by Josh Cogliati
Modified: 2016-02-23 15:50 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-02-23 15:50:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Josh Cogliati 2013-12-15 15:55:46 UTC
Description of problem:
The release keys at https://fedoraproject.org/keys are self signed.  I think that the release keys should be signed by the previous version.  

Version-Release number of selected component (if applicable):
fedora-release-19-5.noarch

How reproducible:
Very.

Steps to Reproduce:
1. wget https://fedoraproject.org/static/246110C1.txt
2. gpg --import 246110C1.txt
3. gpg --check-sigs 246110C1

Actual results:
pub   4096R/246110C1 2013-05-16
uid                  Fedora (20) <fedora>
sig!3        246110C1 2013-05-16  Fedora (20) <fedora>


Expected results something like:
pub   4096R/246110C1 2013-05-16
uid                  Fedora (20) <fedora>
sig!3        246110C1 2013-05-16  Fedora (20) <fedora>
sig!         FB4B18E6 2013-05-16  Fedora (19) <fedora>

Additional info:
I expected that the Fedora (20) key should have been signed by the Fedora (19) key.  This would let me verify that somehow or other the Fedora (20) key I am downloading has not been substituted.  

This has been complained about on the web at
http://www.reddit.com/r/linux/comments/rfvhl/why_arent_the_fedora_gpg_keys_signed_question_in/

Comment 1 Dennis Gilmore 2013-12-16 21:55:22 UTC
Reassigning to sigul because AFAIK it doesn't allow us to sign other keys. note that we are shipping keys for newer rleases in older releases fedora-release packages. you can build trust that way.

Comment 2 Fedora End Of Life 2015-05-29 09:59:58 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Josh Cogliati 2015-05-29 12:09:51 UTC
Still in Fedora 22
$ gpg --check-sigs 8E1431D5 A29CB19C
pub   4096R/8E1431D5 2014-07-09
uid                  Fedora (22) <fedora>
sig!3        8E1431D5 2014-07-09  Fedora (22) <fedora>

pub   4096R/A29CB19C 2014-07-09
uid                  Fedora Secondary (22) <fedora>
sig!3        A29CB19C 2014-07-09  Fedora Secondary (22) <fedora>
sub   4096g/9A007DB4 2014-07-09
sig!         A29CB19C 2014-07-09  Fedora Secondary (22) <fedora>

Comment 4 Dennis Gilmore 2016-02-23 15:50:29 UTC
We do not have access to the keys to be able to fulfill this request.


Note You need to log in before you can comment on or make changes to this bug.