Bug 1315076

I thing you just hit the f24 repository during development before release. The fedora rawhide repository (f25) is with unsigned packages, fedora-23 repository is with signed packages. Fedora 24 is just in progress between this 2 stages. We would prefer that repositories behave in one way with no exceptions. Probably if more user will request same RFE with good user cases, we will add the feature, but at the time I have to close it.

What if some 3rd-party repo will start having
the unsigned packages? The upgrade process will
be broken just by that.

No, gpgcheck option can be used in dnf.conf file, .repo file or from command line. The logic is like this: the option in dnf.conf file is overwritten by option from .repo if is defined. The option gpgcheck in dnf.conf and .repo is overwritten by command line option --nogpgcheck . As you can see it is complex multilevel setting that can be easily tuned. It is possible to use repository with signed packages and repository with unsigned packages in single transaction. Only it is impossible to apply different gpg-check rules for a packages inside certain repository.

Note:
dnf.conf - applied to all repositories
.repo - applied to this repository

Yes, I mean exactly if the 3-rd party repo will
release some unsigned packages by mistake, even
when you fix all the official repos to not do such
a mix. Say, the 3-rd party repo releases just 1
unsigned package with the rest are still signed.
If it does so, the upgrade will be broken for all
repos at once, until you either disable the offending
repo or disable the gpgcheck for it (you may not
want to do either).

Yes, it will be like it. But think in other direction, if some unauthorized person manipulate a repository by adding some unsigned packages, they can be easily hidden. But if no one will be able to install them, they receive an attention. We really think that current behavior is correct and more secure that proposed changes.

I just hit this problem and I'm sad to see this as a closed bug.

I have one package missing a signature. I dont even know what repository it is in. Yet, I want my system to be updated as best as possible. It is currently preventing 250+ packages to get updated for no good reason other than me not knowing how to say "skip the one bad package".

One has to be a fedora developer to get this system updated, and that is wrong. This should work for mortals too.

This should be reconsidered. I understand Stas's view but I think in reality it does not work very well. In reality people will probably just turn off that repository and not turn it back on thus never get bug and security fixes. Which could be a bigger problem. With a flag at least they could skip it for the current update and then they would be reminded each time they had to update because they had to continue to add the flag.

I think the problem should be solved at the right place. The problem is that after branching from rawhide the new repository contains signed and unsigned packages but it use policy to verify gpgkeys. The best solution would be to release that repo at the state that all packages will be signed. Also question is if packages in rawhide can be also signed, therefore the problem will not appear later on.

What does DNF:
1. Every time it checks checksums
2. According to setting of repository we check gpg keys for each package (rpm does). GPG check confirms the origin of the package and enabling hybrid behavior could result in security problem. But if you don't care about origin of packages and you trust the content of all Fedora mirrors, just use --nogpgcheck because there is no difference between the requested feature and nogpgcheck option.

I think the problem should be solved by infrastructure level and not on DNF level, therefore I am changing the component.

(In reply to Jaroslav Mracek from comment #9)
> (rpm does). GPG check confirms the origin of the package and enabling hybrid
> behavior could result in security problem. But if you don't care about
> origin of packages and you trust the content of all Fedora mirrors, just use
> --nogpgcheck because there is no difference between the requested feature
> and nogpgcheck option.

The requested feature was to skip the unsigned packages,
not to install them. So the similarity to --nogpgcheck
looks moot.
Your original argument was in comment #6 with the
point being to get the user's attention to the problem.
This is a valid argument, but there are better ways
to get user's attention than to break the upgrade
completely. Namely, with a loud warning suggesting
to disable the repo in question, asking his confirmation
to continue, etc. At the very least you can add an option
to do that thing if you don't want this by default.
There is already a --nogpgcheck option, so why a much
less dangerous option --skip-unsigned can not exist?

(In reply to Jaroslav Mracek from comment #9)
> I think the problem should be solved at the right place. The problem is that
> after branching from rawhide the new repository contains signed and unsigned
> packages but it use policy to verify gpgkeys. The best solution would be to
> release that repo at the state that all packages will be signed. Also
> question is if packages in rawhide can be also signed, therefore the problem
> will not appear later on.

This has already been done as of F26. When we branched f26 from rawhide, both repos were fully signed when pushed out. 
 
> What does DNF:
> 1. Every time it checks checksums
> 2. According to setting of repository we check gpg keys for each package
> (rpm does). GPG check confirms the origin of the package and enabling hybrid
> behavior could result in security problem. But if you don't care about
> origin of packages and you trust the content of all Fedora mirrors, just use
> --nogpgcheck because there is no difference between the requested feature
> and nogpgcheck option.

I have no horse in this race, but thats not true. --nogpgcheck will install all the packages, signed or not. The reporter is asking for a way to only installed signed packages and remove the unsigned ones from the transaction (and I assume any signed ones that depend on those. 

So if you have foo-1.0-1, bar-1.0-1 and baz-1.0-1 in your update set and bar depends on baz and baz is not signed, you get: 

with --nogpgcheck: 

foo, bar and baz are all updated. 

with --skip-unsigned: 

only foo is updated and there's a message about baz not being signed and bar not being upgradable because it needs baz upgraded. 

In any case it's up to you if you want to implement this... 

> 
> I think the problem should be solved by infrastructure level and not on DNF
> level, therefore I am changing the component.

There's nothing more to do on the infrastructure end.

I am sorry for misunderstanding of this request. I am really happy to hear that all packages are signed. This is really perfect.

Anyway I do not support the request due to we check gpg keys during transaction and skipping unsigned packages can produce broken dependency or only fail at the same place - transaction check. We don't know if the package is signet or not before downloading, but any problem here is fatal for dnf due to that we have to ensure that all dependency will be fulfill.

Thanks once more to release engineers for solving the primary cause of the problem.