See that update fails, because RPM can't update Chrome to a newer version. sudo dnf update, or use GNOME Software to updateĦ. sudo update-crypto-policies -set DEFAULTĥ. sudo dnf install ' ' # this is an older version of ChromeĤ. You can also use DEFAULT:SHA1, but that only fixes select cases, not all.ģ. sudo update-crypto-policies -set LEGACY # to allow crypto which was allowed in F37 and earlier. While you can install F37 with current Chrome, upgrade to F38, and then wait a few weeks for a new Chrome release, a faster approach is:Ģ. In order to replicate the state, you'll want an F38 installation with an older Google Chrome version installed, so that there is an already available update for Chrome. Version-Release number of selected component (if applicable): This would make users aware of the problem and force them to deal with it before it negatively affects the OS. Perhaps we could:ĭ) detect affected packages on F36/37 and warn users before upgrade, or even better, prevent the upgrade from starting. Having the above fixed would improve the situation, but it still wouldn't help with system updates being blocked when insecure packages are in the transaction. There are a number of things which feel like a problem in RPM:Ī) RPM shouldn't claim that installed packages are not installed, just because they no longer conform to security policiesī) RPM should allow to figure out which packages are affectedĬ) RPM should allow to remove affected packages from the system This may result in a big chunk of our users no longer applying general system updates, making their systems insecure. General audience is likely to have troubles to even find an article describing the solution.ģ. Users are extremely unlikely to figure out the solution to the problem on their own, they'll need external help. A large portion of our user base is likely to be affected (Chrome, Dropbox, VSCode, etc - all very popular).Ģ. The combination of the problems mentioned above means:ġ. (And GUI-only users won't be able to update any packages at all). Even if the vendor bumps the security signatures on RPMs and repo keys and publishes updates, the existing F38 systems will not be able to update those packages (without manual intervention) - at least that's my current assumption. The problem exists with currently installed RPMs - they can't be even removed, which means they can't be updated either. = 4) System will not fix itself even if vendor fixes their RPMs, a manual intervention is necessary = See an attached screenshot for an attempt to update the system using GNOME Software. You can remove cached packages by executing 'dnf clean packages'. The downloaded packages were saved in cache until the next successful transaction. Google-chrome-stable x86_64 1.100-1 google-chrome Last metadata expiration check: 0:05:28 ago on Fri 12:43:41 PM CET. = 3) System can't be updated, if an affected RPM is in the transaction = See an attached screenshot for an attempt to remove Chrome in GNOME Software. Google-chrome-stable x86_64 1.119-1 303 MĮrror: An rpm exception occurred: package not installed = 2) System can't remove the affected RPMs = Google-chrome-stable.x86_64 1.119-1 problem also means that it is quite difficult to figure out if and which affected RPMs are present on the system. $ sudo dnf list -installed google-chrome-stable This is clearly saying google-chrome-stable is not installed, while it is (you can run it just fine from your app menu). Package google-chrome-stable is not installed Header V4 DSA/SHA1 Signature, key ID 7fac5991: BAD = 1) System doesn't show affected RPMs as installed =Įrror: rpmdbNextIterator: skipping h# 2525 Unless otherwise noted, the following examples are from Fedora 37 Workstation with Google Chrome installed (from their official repo) and then upgraded to Fedora 38 Workstation: However, people who *upgrade* to F38 and already have some affected RPMs installed will see serious consequences:ġ) System doesn't show affected RPMs as installed (in `rpm -qa` or `rpm -q`)Ģ) System can't remove the affected RPMs (with `rpm -e` or `dnf remove` or PackageKit)ģ) System can't be updated, if an affected RPM is in the transaction (`dnf update`, PackageKit)Ĥ) System will not fix itself even if vendor fixes their RPMs, a manual intervention is necessary But overall there seems to be no negative impact on the OS in general. RPM rejects them based on their RPM signature or the repo key signature (as far as I understand it). Please read the problem description here first:įor fresh F38 installations, the only consequence seems to be that many popular third-party software can't be installed. This is an attempt to summarize the impact of an F38 change to enforce security policies in RPM on our user base, and describe the discovered problems.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |