Something seems to have changed in the last couple of weeks, breaking installation from our (third-party) rpm repository. Our `brave-browser` package requires a `brave-keyring` package which installs a package-signing key in support of future key rotations. When just `brave-browser` is requested, dnf resolves the `brave-keyring` dependency to version 1.8, which contains an already-rotated key and install fails: error: Verifying a signature using certificate D8BAD4DE7EE17AF52A834B2D0BB75829C2D4E821 (Brave Software <support>): Certificate 0BB75829C2D4E821 invalid: policy violation because: No binding signature at time 2020-03-18T20:45:09Z error: Verifying a signature using certificate D8BAD4DE7EE17AF52A834B2D0BB75829C2D4E821 (Brave Software <support>): Certificate 0BB75829C2D4E821 invalid: policy violation because: No binding signature at time 2020-03-18T20:45:10Z Problem opening package brave-keyring-1.8-1.noarch.rpm If `brave-keying` is requested directly, it resolves to version 1.11, which works fine. Reproducible: Always Steps to Reproduce: Following the installation instructions from https://brave.com/linux in a container: 1. podman run --rm -ti fedora 2. dnf install dnf-plugins-core 3. dnf config-manager --add-repo https://brave-browser-rpm-release.s3.brave.com/brave-browser.repo 4. rpm --import https://brave-browser-rpm-release.s3.brave.com/brave-core.asc 5. dnf install brave-browser Actual Results: `brave-keyring` 1.8 is selected, and installation fails Expected Results: Latest version of `brave-keyring` should be selected by the resolver, which is signed by the current bootstrap key. I'd be happy to hear this is some problem with our repo data or spec file, but we haven't changed how we generate that, and I can't find anything wrong with it. Regardless, I'd expect the same version from either an unversioned "requires" or a direct install request.
FWIW, I can reproduce this in a `fedora:38` container (ded636d6da3e), but not `fedora:37` (42acab067ad9).
Thanks for the report! Although I understand your frustration (installing the older version of a dependency leads to an unnecessary upgrade of the package during the next run), the solution would not be simple. And the current solver's solution is correct - the 'brave-browser' requires ANY version of 'brave-keyring', which is fulfilled. There are several factors that may affect the final solution: - The version of the dnf stack (dnf, libdnf, and most importantly libsolv, which is responsible for performing the complex task of resolving dependencies). - A set of currently installed packages. - The size of the resolved dependency tree for different versions of 'brave-keyring.' In this case, I think the most important factors are the last two. 'brave-keyring' version 1.8 was the last one that did not require the 'at' package as a dependency, which definitely affects the number of packages in the transaction. Also, the installed package set is important - while experimenting with your use case, a simple upgrade of 'systemd-libs' in F38 container led to a different solution with the latest 'brave-keyring' present. To resolve this, I would recommend two steps: - Change 'brave-browser' dependencies to require 'brave-keyring' > 1.8 (or whatever suitable version) to immediately mitigate the issue. - The permanent solution would require preparing a minimal libsolv reproducer (preferably in the format of a libsolv testcase) and filing an issue for libsolv upstream at https://github.com/openSUSE/libsolv.
Fascinating! Thanks for the comprehensive reply. In particular, bumping the required keyring package version when the signing key is rotated should be straightforward. I just always assumed the resolver would choose the newest compatible package!
I'm not familiar with your use-case, but just an idea - would it make sense to not deliver old brave-keyring packages and remove them from the repo? Or are they needed for someone (e.g. old Fedoras...)?
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.