January 2025 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1233824] New: [s390x] gnome-remote-desktop RDP-server does not start on s390x
by bugzilla_noreply＠suse.com 18 Mar '25

18 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1233824 Bug ID: 1233824 Summary: [s390x] gnome-remote-desktop RDP-server does not start on s390x Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: martin.sirringhaus(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I can't get RDP to work on s390x, so I tried the same steps on a x86_64 VM and on s390x: ``` sudo zypper in -y gnome-remote-desktop freerdp-server # You probably have to do `su -` here first for this one: sudo -u gnome-remote-desktop winpr-makecert \ -silent -rdp -path ~gnome-remote-desktop rdp-tls # Set RDP_USER and RDP_PASS to whatever you want sudo grdctl --system rdp set-credentials "$RDP_USER" "$RDP_PASS" sudo grdctl --system rdp set-tls-key /var/lib/gnome-remote-desktop/rdp-tls.key sudo grdctl --system rdp set-tls-cert /var/lib/gnome-remote-desktop/rdp-tls.crt sudo grdctl --system rdp enable sudo systemctl --now enable gnome-remote-desktop.service ``` On both systems I get basically the same output for this: ``` # grdctl --system status Init TPM credentials failed because No TPM device found, using GKeyFile as fallback. Overall: Unit status: active RDP: Status: enabled Port: 3389 TLS certificate: /var/lib/gnome-remote-desktop/rdp-tls.crt TLS fingerprint: 1f:76:bb:d3:bd:42:fd:51:af:e7:89:64:e1:00:c2:78:d9:16:20:63:2b:08:84:ac:38:4e:79:48:c9:4a:07:db TLS key: /var/lib/gnome-remote-desktop/rdp-tls.key Username: (hidden) ``` `systemctl start gnome-remote-desktop` works fine on both systems, telling me that the service is up and running. On my VM, however, I get ``` Nov 27 14:04:03 localhost.localdomain systemd[1]: Starting GNOME Remote Desktop... Nov 27 14:04:03 localhost.localdomain gnome-remote-de[4244]: Init TPM credentials failed because No TPM device found, using GKeyFile as fallback Nov 27 14:04:03 localhost.localdomain systemd[1]: Started GNOME Remote Desktop. Nov 27 14:04:04 localhost.localdomain gnome-remote-de[4244]: RDP server started localhost:~ # ss -punta | grep gnome tcp LISTEN 0 10 *:3389 *:* users:(("gnome-remote-de",pid=4244,fd=9)) ``` whereas on s390x, I get: ``` Nov 27 12:47:41 firefox.prg2.suse.org systemd[1]: Starting GNOME Remote Desktop... Nov 27 12:47:41 firefox.prg2.suse.org gnome-remote-de[15170]: Init TPM credentials failed because No TPM device found, using GKeyFile as fallback Nov 27 12:47:41 firefox.prg2.suse.org systemd[1]: Started GNOME Remote Desktop. firefox:~ # ss -punta | grep gnome firefox:~ # ``` Setting G_MESSAGES_DEBUG=all didn't reveal anything, either. Basically, all RDP-related output is missing on s390x. No additional info (that is not also logged on x86_64 with this env-variable). The RDP-server simply doesn't start up on s390x without any errors or logging. -- You are receiving this mail because: You are on the CC list for the bug.

1 36

[Bug 1222192] New: Package description for cadvisor shows trivy
by bugzilla_noreply＠suse.com 17 Mar '25

17 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1222192 Bug ID: 1222192 Summary: Package description for cadvisor shows trivy Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: holdenrf2021(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Also shows on https://software.opensuse.org/package/cadvisor $ sudo zypper if trivy cadvisor [sudo] password for root: Loading repository data... Reading installed packages... Information for package trivy: ------------------------------ Repository : Main Repository (OSS) Name : trivy Version : 0.49.1-1.2 Arch : x86_64 Vendor : openSUSE Installed Size : 274.2 MiB Installed : No Status : not installed Source package : trivy-0.49.1-1.2.src Upstream URL : https://github.com/aquasecurity/trivy Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. Information for package cadvisor: --------------------------------- Repository : Main Repository (OSS) Name : cadvisor Version : 0.46.0-1.8 Arch : x86_64 Vendor : openSUSE Installed Size : 29.9 MiB Installed : No Status : not installed Source package : cadvisor-0.46.0-1.8.src Upstream URL : https://github.com/google/cadvisor Summary : A Simple and Comprehensive Vulnerability Scanner for Containers Description : Trivy (`tri` pronounced like trigger, `vy` pronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1236057] New: Systemd cannot create cockpit runtime directory with selinux on slowroll
by bugzilla_noreply＠suse.com 17 Mar '25

17 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1236057 Bug ID: 1236057 Summary: Systemd cannot create cockpit runtime directory with selinux on slowroll Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: rein+suse(a)purelymail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- With selinux enabled I keep getting this error when starting cockpit: cockpit-certificate-ensure[20388]: cockpit-certificate-ensure: mkdir: /run/cockpit/tls/server: File exist The selinux alert corresponding to it is SELinux is preventing systemd from rmdir access on the directory clients. For complete SELinux messages run: sealert -l d8166a7f-d4e3-4013-bd9e-52939f11bb45 Seems like systemd is prohibited from creating the runtime directory. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1230281] New: crash: dminfo.so reproducible builds issue
by bugzilla_noreply＠suse.com 17 Mar '25

17 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1230281 Bug ID: 1230281 Summary: crash: dminfo.so reproducible builds issue Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1102408 Target Milestone: --- Found By: Development Blocker: --- Created attachment 877173 --> https://bugzilla.suse.com/attachment.cgi?id=877173&action=edit diff of strings output While working on reproducible builds for openSUSE, I found that our crash package's dminfo.so varied between -j1 and -j4 (kvm) osc builds The -j1 version contains the string _ITM_deregisterTMCloneTable while the -j4 version does not. This indicates that there is some build-time race condition that causes this and it should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1234800] New: GRUB_SAVEDEFAULT does not work on encrypted system
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1234800 Bug ID: 1234800 Summary: GRUB_SAVEDEFAULT does not work on encrypted system Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: linus.kardell(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I have a laptop installed on btrfs on LUKS. If I try to enable GRUB_SAVEDEFAULT in /etc/default/grub, I get en error saying "../../grub-core/commands/loadenv.c:216:sparse file not allowed." when booting. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1226207] New: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1226207 Bug ID: 1226207 Summary: breeze-dark (kf6-breeze-icons) symbolic icons aren't recolored and dark though should be light Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: w01dnick(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- kf6-breeze-icons generate identical icons for both breeze & breeze-dark. While this is not an issue for KF6 apps, that use run-time recoloring, in KF5 apps, like Krusader, when dark color theme is used and icons are breeze-dark symbolic icons are dark on dark background and almost invisible. The reason is this build option: `-DWITH_ICON_GENERATION:BOOL=FALSE` I've tried to make my custom build [1] switching it to TRUE and breeze-dark icons are fine with Krusader now. But I don't know the reasoning behind switching it to FALSE. There is comment: ``` saves ~30MB and installs dangling symlinks ``` Less size is true, though IMHO it's not a good solution to break KF5 apps to save some space. But I can't see any dangling symlinks: ``` find /usr/share/icons/breeze{,-dark} -xtype l ``` doesn't find anything. Any other reason or should I cleanup [1] and make a submit request? [1] https://build.opensuse.org/package/show/home:NickLion:branches:KDE:Framewor… -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1234741] New: Only "systemd-boot" or "grub2-bls" are recognized (end of dup)
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1234741 Bug ID: 1234741 Summary: Only "systemd-boot" or "grub2-bls" are recognized (end of dup) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: pj.opensuse(a)gmx.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hi, Tumbleweed snapshot 20241218 after zypper ref *and* zypper dup are passed......the following is displayed in konsole... %posttrans(dracut-pcr-signature-0.5+1-1.1.noarch) script output: Error: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized. %transfiletriggerin(sdbootutil-1+git20241217.5aeb4e9-1.1.x86_64) script output: Error: Bootloader not detected. /etc/sysconfig/bootloader has LOADER_TYPE="grub2-efi", but only "systemd-boot" or "grub2-bls" are recognized. warning: %transfiletriggerin(sdbootutil-1+git20241217.5aeb4e9-1.1.x86_64) scriptlet failed, exit status 1 Running post-transaction scripts .......................................................................................................[done] What is going on here? -Thanks -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1234587] New: VUL-0: CVE-2024-45337: copacetic: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1234587 https://bugzilla.suse.com/show_bug.cgi?id=1234587#c1 Bug ID: 1234587 Summary: VUL-0: CVE-2024-45337: copacetic: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: containers-bugowner(a)suse.de Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- --- Comment #1 from Andrea Mattiazzo <andrea.mattiazzo(a)suse.com> --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1229338] New: ffmpeg fails to build on 32bit arm
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1229338 Bug ID: 1229338 Summary: ffmpeg fails to build on 32bit arm Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/4414868/modules/star t_install/steps/3 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ffmpeg-6 and ffmpeg-7 fail to build on armv6hl as well as armv7hl, turning desktops uninstallable. This patch should fix it: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=654bd47716c4f36719fb0f3f7f… ## Observation openQA test in scenario opensuse-Tumbleweed-NET-arm-install_only@aarch32 fails in [start_install](https://openqa.opensuse.org/tests/4414868/modules/start_inst… ## Test suite description set HDDSIZE=40 as required for ppc64le (failed w/o it on https://openqa.opensuse.org/tests/390330#step/install_and_reboot/21 ## Reproducible Fails since (at least) Build [20240524](https://openqa.opensuse.org/tests/4222103) ## Expected result Last good: [20240523](https://openqa.opensuse.org/tests/4218706) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=arm&distri=opensuse&f… -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1215945] New: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed)
by bugzilla_noreply＠suse.com 14 Mar '25

14 Mar '25

https://bugzilla.suse.com/show_bug.cgi?id=1215945 Bug ID: 1215945 Summary: ffmpeg-4: Build fails with current Binutils; requires 'asm' fix (15.4, 15.5, Tumbleweed) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Keywords: build Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: burnus(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: jengelh(a)inai.de Target Milestone: --- Found By: --- Blocker: --- GNU Binutils 2.41 now reveals a bug in the 'asm' code used in ffmpeg-4: ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' While Binutils is pending for opensuse:factory, the new version has already landed in 15.4 and 15.5 such that ffmpeg-4 fails there: https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 ffmpeg-5/6 seemingly got the fix as I do see no fails for 15.4/15.5 for the build of the 4h old package. Upstream FIX: "Fixes assembling with binutil as >= 2.41" at https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/effadce6c756247ea8bae32… See also https://trac.ffmpeg.org/ticket/10405 or (where I found it): The pending Binutils update for openSUSE:factory update is: https://build.opensuse.org/request/show/1113885 -- You are receiving this mail because: You are on the CC list for the bug.

1 3