We probably know people who know people. I’ll ask around to see what’s being pursued.
Obvious to who? I have Fedora running right now in WSL and Google runs on Linux (even has its own custom Linux distro).
Thanks. I’m particularly interested in Edge.
Haven’t upgraded to F38 yet, how do we verify this will be an issue or not?
I tried rpm -qi [package] on code and brave-browser, but both say they use SHA/256 or SHA/512 for signature.
Code:
Signature : RSA/SHA256, Mon 09 Jan 2023 01:23:39 PM, Key ID eb3e94adbe1229cf
Brave:
Signature : RSA/SHA512, Wed 25 Jan 2023 05:59:17 PM, Key ID a8580bdc82d3dc6c
That’s a good question and I have no answer. So far, only Google Chrome seems to have a weak RPM package signature (DSA/SHA1). This would print packages having SHA1:
for PKG in $(rpm -qa); do rpm -qi $PKG | grep Signature | grep -q SHA1 && echo "Outdated SHA1 signature: $PKG"; done
However, the policy forbids many more things than just SHA1. I don’t know how to check it fully in advance.
Also, all other listed apps (Edge, VSCode, etc) seem to have a strong RPM package signature, but a weak repo key signature. RPM then refuses to import that key:
$ sudo rpm --import 'https://packages.microsoft.com/keys/microsoft.asc'
error: Certificate EB3E94ADBE1229CF:
Policy rejects EB3E94ADBE1229CF: No binding signature at time 2023-02-20T09:08:46Z
error: https://packages.microsoft.com/keys/microsoft.asc: key 1 import failed.
You can see your current repos in /etc/yum.repos.d/*.repo, their repo keys are defined in a gpgkey= field. Again, I’m not sure how to check this against a future (F38) RPM, apart from installing F38 in a virtual machine or a container and just trying.
I’m seeing this while trying to update AnyDesk using the CentOS repo (workaround because the Fedora package doesn’t have the right deps)
$ sudo dnf update -y
[sudo] password for asinha:
Last metadata expiration check: 0:36:01 ago on Mon 20 Mar 2023 13:53:21 IST.
Dependencies resolved.
Problem: package vlc-core-1:3.0.18-4.fc38.x86_64 requires libmpcdec.so.5()(64bit), but none of the providers can be installed
- cannot install both libmpcdec-1.3.0-0.1.20110810svn475.fc38.x86_64 and libmpcdec-1.2.6-31.fc38.x86_64
- cannot install the best update candidate for package vlc-core-1:3.0.18-4.fc38.x86_64
- cannot install the best update candidate for package libmpcdec-1.2.6-31.fc38.x86_64
================================================================================
Package Arch Version Repository Size
================================================================================
Upgrading:
anydesk x86_64 6.2.1-1.el7 anydesk 5.0 M
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
libmpcdec x86_64 1.3.0-0.1.20110810svn475.fc38 updates-testing 42 k
Transaction Summary
================================================================================
Upgrade 1 Package
Skip 1 Package
Total size: 5.0 M
Downloading Packages:
[SKIPPED] anydesk-6.2.1-1.el7.x86_64.rpm: Already downloaded
Running transaction check
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: An rpm exception occurred: package not installed
I’ve set the security policy to LEGACY, and I have the latest crypto policies too, the one that is meant to fix this common issue. Is there anything else I need to do?
rpm -q crypto-policies
crypto-policies-20230301-1.gita12f7b2.fc38.noarch
sudo update-crypto-policies --show
LEGACY
Thanks,
@ankursinha Please provide the output of this:
rpm -q crypto-policies rpm-sequoia
Also, please set the policy to the default:
sudo update-crypto-policies --set DEFAULT
Now, do you still see rpmdbNextIterator: skipping errors in:
rpm -qa > /dev/null
?
Can you update AnyDesk now?
What is the output of this?
rpm -q --nosignature --querybynumber 30
Installing and running AnyDesk in a live session of Fedora 38 beta works for me.
Assuming you have upgraded, make sure your configs are up to date.
If the issue persists, try rebuilding the RPM database.
Here are the outputs:
$ rpm -q crypto-policies rpm-sequoia
crypto-policies-20230301-1.gita12f7b2.fc38.noarch
rpm-sequoia-1.3.0-1.fc38.x86_64
$ sudo update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
$ rpm -qa > /dev/null
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
$ rpm -q --nosignature --querybynumber 30
anydesk-6.1.1-1.x86_64
and here is the attempt to upgrade:
$ sudo dnf list --upgrades
Fedora 38 - x86_64 29 kB/s | 23 kB 00:00
Fedora 38 - x86_64 285 kB/s | 2.8 MB 00:10
Fedora 38 - x86_64 - Updates 11 kB/s | 4.4 kB 00:00
Fedora 38 - x86_64 - Test Updates 12 kB/s | 5.1 kB 00:00
Fedora 38 - x86_64 - Test Updates 112 kB/s | 484 kB 00:04
Available Upgrades
anydesk.x86_64 6.2.1-1.el7 anydesk
libmpcdec.x86_64 1.3.0-0.1.20110810svn475.fc38 updates-testing
$ sudo dnf update -y
Last metadata expiration check: 0:00:40 ago on Tue 21 Mar 2023 12:46:18 IST.
Dependencies resolved.
Problem: package vlc-core-1:3.0.18-4.fc38.x86_64 requires libmpcdec.so.5()(64bit), but none of the providers can be installed
- cannot install both libmpcdec-1.3.0-0.1.20110810svn475.fc38.x86_64 and libmpcdec-1.2.6-31.fc38.x86_64
- cannot install the best update candidate for package vlc-core-1:3.0.18-4.fc38.x86_64
- cannot install the best update candidate for package libmpcdec-1.2.6-31.fc38.x86_64
=============================================================================================================================================================================
Package Architecture Version Repository Size
=============================================================================================================================================================================
Upgrading:
anydesk x86_64 6.2.1-1.el7 anydesk 5.0 M
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
libmpcdec x86_64 1.3.0-0.1.20110810svn475.fc38 updates-testing 42 k
Transaction Summary
=============================================================================================================================================================================
Upgrade 1 Package
Skip 1 Package
Total download size: 5.0 M
Downloading Packages:
anydesk-6.2.1-1.el7.x86_64.rpm 1.7 MB/s | 5.0 MB 00:02
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.7 MB/s | 5.0 MB 00:02
Running transaction check
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: An rpm exception occurred: package not installed
This is an upgrade from F37, and I’ve already run the post-installation cleanup steps:
$ sudo rpmconf -a
# nothing
Attempting to uninstall anydesk also errors:
$ sudo dnf remove anydesk
Dependencies resolved.
=============================================================================================================================================================================
Package Architecture Version Repository Size
=============================================================================================================================================================================
Removing:
anydesk x86_64 6.1.1-1 @anydesk 13 M
Removing unused dependencies:
gtkglext-libs x86_64 1.2.0-44.fc38 @fedora 573 k
minizip-compat x86_64 1.2.13-3.fc38 @fedora 55 k
Transaction Summary
=============================================================================================================================================================================
Remove 3 Packages
Freed space: 14 M
Is this ok [y/N]: y
Running transaction check
error: rpmdbNextIterator: skipping h# 30
Header V4 RSA/SHA512 Signature, key ID cdffde29: BAD
Header SHA1 digest: OK
Error: An rpm exception occurred: package not installed
I haven’t tried rebuilding the rpmdb, but I want to hold off doing that until we’ve diagnosed the issue here—since folks upgrading shouldn’t be expected to rebuild their rpmdbs.
I reopened https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c107 and described your issue there. The problem is with your currently installed package anydesk-6.1.1-1.x86_64, and not 6.2.1 you’re trying to install from the Centos repo. I assume you installed 6.1.1 from the official AnyDesk source. It’s interesting that you managed to install exactly this version, because on my F37, it fails with:
nothing provides libpangox-1.0.so.0()(64bit) needed by anydesk-6.1.1-1.x86_64
But it doesn’t matter, because the el7 and el8 versions also exhibit the same problem, as described in the bug report. The devs will hopefully look at it and let us know.
Thanks very much @kparal .
I think I installed it quite a while ago, and I’ve just been upgrading since so that package hasn’t changed. The Fedora repo Anydesk provides also has a broken anydesk package, which is why folks suggested we use the el7/el8 package/repo instead.
The pango dep required us to dig up an ancient compat package:
$ sudo dnf whatprovides 'libpangox-1.0.so.0()(64bit)'
Last metadata expiration check: 2:44:11 ago on Tue 21 Mar 2023 12:47:26 IST.
pangox-compat-0.0.2-15.fc31.x86_64 : Compatibility library for pangox
Repo : @System
Matched from:
Provide : libpangox-1.0.so.0()(64bit)
Looks like it’s still available on koji here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1332559
would this help ?
any solution for the VLC problem ?
We’re not discussing VLC here, please create a separate topic for it, thanks.
Still having issues with this in a very reproducible way.
- With fedora toolbox create toolbox --release 38
- toolbox enter fedora-toolbox-38
- su -
- dnf update -y
- enable copr agriffis/neovim-nightly
- dnf install python3-neovim
with result:
Problem opening package python3-neovim-0.4.3.0.git.601.71102c0-1.fc38.noarch.rpm
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
⬢[root@toolbox ~]#
I have tried to add --nogpgcheck with the same results
Also tried
sudo update-crypto-policies --set LEGACY
with no success. Any further suggestions here?
FYI: The simple dnf update on the fresh f38 toolbox also terminated with:
Failed:
shadow-utils-2:4.13-4.fc38.x86_64 shadow-utils-2:4.13-6.fc38.x86_64
This might be caused by having old crypto-policies and rpm*, yes. Which means the rpm signature issues are still present. The toolbox image content is old and doesn’t include even Beta packages. I assume the image would get re-generated once F38 is Final, but I’m not sure who to ask to confirm. @adamwill Would you know?
I can confirm this in the my own F38 toolbox:
Error unpacking rpm package shadow-utils-2:4.13-6.fc38.x86_64
Running scriptlet: rpm-4.18.1-1.fc38.x86_64 43/116
error: unpacking of archive failed on file /usr/bin/newgidmap;64254ae7: cpio: cap_set_file failed - No data available
error: shadow-utils-2:4.13-6.fc38.x86_64: install failed
Can you please file a bug against shadow-utils in https://bugzilla.redhat.com and link it here? Thanks!
https://bugzilla.redhat.com/show_bug.cgi?id=2183034
Sorry this should really have been a separate thread! (shadow-utils issue)
@rishi might be able to help with rebuilding the container image. I’m not sure if there’s a regular schedule for that; there probably should be.
fedpkg container-build is currently broken and preventing the images from being rebuilt: Issue #11367: 'fedpkg container-build' fails with Python TypeError - releng - Pagure.io
The images are manually rebuilt at the moment with a fedpkg container-build followed by the Bodhi dance. We have been trying to change that for a while. Hopefully, we will make some progress for Fedora 39.
By the way, in case you are not changing the image definitions, but just doing a simple rebuild, then don’t be afraid to go ahead and do it. You don’t have to edit anything in dist-git. Just fedpkg container-build and Bodhi.
We have put in some self-tests to the Dockerfile which should catch breakages caused by files going inadvertently missing from the images. We will try to enhance that to make things as robust as possible.
A new fedora-toolbox:38 build is now in Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-CONTAINER-2023-5046242970
Many thanks to @kevin for fixing the build system in record time!