Bug 502277 - unsigned packages should be considered broken for --skip-broken
unsigned packages should be considered broken for --skip-broken
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: 502635 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-05-22 21:47 EDT by Tom Horsley
Modified: 2014-01-21 18:09 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-22 23:10:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2009-05-22 21:47:21 EDT
Description of problem:

A couple of unsigned packages have crept into rawhide recently. I just
tried to ignore them by using --skip-broken and got the exact same errors
with and without the --skip-broken option. An unsigned package in a repo
configured to require signed packages seems (to me anyway) like something
that should fall into the category "broken", it would be convenient if
--skip-broken skipped them.

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

How reproducible:
Every time

Steps to Reproduce:
1. see above
Actual results:

Expected results:

Additional info:
Comment 1 James Antill 2009-05-22 23:10:18 EDT
 --skip-broken is about package sets that don't depsolve, so we remove them from the transaction at that point.
 From the technical point of view the yum code basically does:

1. parse command line
2. depsolve
3. download
4. run transaction

...if a package isn't signed, when the repo. says it should be, we only find out at #4 ... which is really late, so it would be much harder to do this.
Comment 2 Tom Horsley 2009-05-22 23:21:53 EDT
Just because it is hard to do, doesn't mean it isn't a good idea.
Shucks, you just need to add --exclude arguments for the unsigned
packages and loop back to step #1. That's what I do manually :-).
Comment 3 Tim Lauridsen 2009-05-23 11:05:46 EDT
i think that --skip-broken is the wrong option for installing unsigned packages.

if you what to force it you can use --nogpgcheck, but that will skip the gpg check for all packages.

One of the problems with skipping packages is that you have to go back to 2. after you have skip packages, because the skip packages can break the whole transaction.

it is not the normal usage case that a repo with gpgcheck=1, has unsigned packages, it's a error in the repo. it is only because the fedora repo has gpgcheck=1, but the packages in the fedora is rawhide and the normal rawhide repo has gpgcheck=0
Comment 4 seth vidal 2009-05-25 22:37:59 EDT
a pkg failing the gpgcheck is a security issue, not a depsolving issue.

These two items should not ever be confused with one another.
Comment 5 seth vidal 2009-05-26 11:39:53 EDT
*** Bug 502635 has been marked as a duplicate of this bug. ***
Comment 6 joshua 2009-05-26 12:01:36 EDT
I agree that it is a security issue... however... the other packages are signed.... so why not install those ?
Comment 7 Tom Horsley 2009-05-26 12:20:22 EDT
I'm not sure anyone actually wanting to use --skip-broken really cares
why the package is broken or thinks it is useful to distinguish somehow
between broken due to dependencies or broken due to being unsigned (or
broken for some other reason if there are others that might crop up).

Maybe the option name should be changed to:


Comment 8 seth vidal 2009-05-26 12:29:46 EDT
The error messages yum outputs are ultimately intended for two different audiences:

1. the user themselves
2. the people who will help support the user and/or debug the problem.

A user not reporting broken deps is an issue but it is not security critical.

A user not reporting an unsigned pkg in a repo that should be signed is CRITICAL.

You can ask to call it what you want - but an unsigned pkg in a signed repo is not 'broken' in the sense we're using it here, it is an emergency.

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