June 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1173919] New: Hawk backend fails to start
by bugzilla_noreply＠suse.com 08 Feb '23

08 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1173919 Bug ID: 1173919 Summary: Hawk backend fails to start Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: john.goutbeck(a)newsignal.ca QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0 Build Identifier: did another fresh clean server install of openSUSE Leap 15.2, use openSUSE repositories set IP zypper in hawk2 zypper in ha-cluster-bootstrap ha-cluster-init - no sbd systemctl restart hawk systemctl restart hawk-backend with the browser (from a Win 10 laptop) https://192.168.12.242:7630/ - get certificate error - accept BLANK screen -- systemctl status hawk ● hawk.service - HA Web Konsole Loaded: loaded (/usr/lib/systemd/system/hawk.service; enabled; vendor preset> Active: active (running) since Mon 2020-07-06 21:43:25 MDT; 17min ago Main PID: 1903 (hawk-apiserver) But not the hawk-backend systemctl status hawk-backend ● hawk-backend.service - HA Web Konsole Backend Loaded: loaded (/usr/lib/systemd/system/hawk-backend.service; static; vendor> Active: failed (Result: exit-code) since Mon 2020-07-06 22:01:52 MDT; 5s ago Process: 14663 ExecStart=/usr/bin/puma.ruby2.5 -C /usr/share/hawk/config/puma> Main PID: 14663 (code=exited, status=1/FAILURE) So, looking at the /var/log/messages file, this is what I get --- 2020-07-06T21:52:07.277099-06:00 nss-leap152 systemd[1]: Started HA Web Konsole Backend. 2020-07-06T21:52:07.393681-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] Puma starting in cluster mode... 2020-07-06T21:52:07.393886-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Version 3.11.0 (ruby 2.5.8-p224), codename: Love Song 2020-07-06T21:52:07.393999-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Min threads: 0, max threads: 1 2020-07-06T21:52:07.394113-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Environment: production 2020-07-06T21:52:07.394231-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Process workers: 1 2020-07-06T21:52:07.394350-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Preloading application 2020-07-06T21:52:07.710011-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] ! Unable to load application: Gem::ConflictError: Unable to activate sass-rails-5.1.0, because railties-5.1.4 conflicts with railties (>= 5.2.0) 2020-07-06T21:52:07.710267-06:00 nss-leap152 puma.ruby2.5[10033]: /usr/lib64/ruby/2.5.0/rubygems/specification.rb:2327:in `raise_if_conflicts': Unable to activate sass-rails-5.1.0, because railties-5.1.4 conflicts with railties (>= 5.2.0) (Gem::ConflictError) 2020-07-06T21:52:07.710480-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/specification.rb:1438:in `activate' 2020-07-06T21:52:07.710599-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' 2020-07-06T21:52:07.710749-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `synchronize' 2020-07-06T21:52:07.710878-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem' 2020-07-06T21:52:07.710991-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/boot.rb:35:in `<top (required)>' 2020-07-06T21:52:07.711074-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711158-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711239-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/application.rb:4:in `<top (required)>' 2020-07-06T21:52:07.711320-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/environment.rb:5:in `require_relative' 2020-07-06T21:52:07.711400-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/environment.rb:5:in `<top (required)>' 2020-07-06T21:52:07.711477-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711573-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711650-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:4:in `block in <main>' 2020-07-06T21:52:07.711726-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:55:in `instance_eval' 2020-07-06T21:52:07.711804-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:55:in `initialize' 2020-07-06T21:52:07.711880-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:in `new' 2020-07-06T21:52:07.711957-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:in `<main>' 2020-07-06T21:52:07.712037-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:49:in `eval' 2020-07-06T21:52:07.712114-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:49:in `new_from_string' 2020-07-06T21:52:07.712186-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:40:in `parse_file' 2020-07-06T21:52:07.712257-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/configuration.rb:318:in `load_rackup' 2020-07-06T21:52:07.712327-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/configuration.rb:243:in `app' 2020-07-06T21:52:07.712401-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/runner.rb:138:in `load_and_bind' 2020-07-06T21:52:07.712472-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/cluster.rb:397:in `run' 2020-07-06T21:52:07.712540-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/launcher.rb:183:in `run' 2020-07-06T21:52:07.712611-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/cli.rb:77:in `run' 2020-07-06T21:52:07.712680-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/bin/puma:10:in `<top (required)>' 2020-07-06T21:52:07.712772-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/bin/puma.ruby2.5:23:in `load' 2020-07-06T21:52:07.712848-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/bin/puma.ruby2.5:23:in `<main>' 2020-07-06T21:52:07.713821-06:00 nss-leap152 systemd[1]: hawk-backend.service: Main process exited, code=exited, status=1/FAILURE 2020-07-06T21:52:07.714104-06:00 nss-leap152 systemd[1]: hawk-backend.service: Unit entered failed state. 2020-07-06T21:52:07.714242-06:00 nss-leap152 systemd[1]: hawk-backend.service: Failed with result 'exit-code'. --- query the rpm nss-leap152:~ # rpm -qa | grep railties ruby2.5-rubygem-railties-5_1-5.1.4-lp152.3.3.x86_64 ruby2.5-rubygem-railties-5.2-5.2.3-lp152.2.3.x86_64 nss-leap152:~ # rpm -qa | grep sass ruby2.5-rubygem-sass-3.5.3-lp152.3.3.x86_64 ruby2.5-rubygem-sass-rails-5.1-5.1.0-lp152.1.1.x86_64 ruby2.5-rubygem-sass-listen-4.0.0-lp152.3.3.x86_64 --- nss-leap152:~ # zypper up Loading repository data... Reading installed packages... Nothing to do. nss-leap152:~ # zypper in -force hawk The flag o is not known. nss-leap152:~ # update-alternatives --config rails There are 2 choices for the alternative rails (providing /usr/bin/rails). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/rails.ruby2.5-5.2.3 50203 auto mode 1 /usr/bin/rails.ruby2.5-5.1.4 50104 manual mode 2 /usr/bin/rails.ruby2.5-5.2.3 50203 manual mode - I chose option 1, 2 and back to 0, still no joy - restart hawk and hawk-backend in-between options. --- zypper in -f hawk2 Loading repository data... Reading installed packages... Forcing installation of 'hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64' from repository 'Main Repository'. Resolving package dependencies... The following package is going to be reinstalled: hawk2 1 package to reinstall. Overall download size: 9.3 MiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving package hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64 (1/1), 9.3 MiB ( 20.6 MiB unpacked) Retrieving: hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64.rpm ..............................................[done (3.7 MiB/s)] Checking for file conflicts: ..................................................................................................[done] (1/1) Installing: hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64 ........................................................[done] Additional rpm output: Updating /etc/sysconfig/hawk ... systemctl restart hawk systemctl restart hawk-backend - still BLANK whit screen - no joy Reproducible: Always Steps to Reproduce: 1. Install Server based openSUSE Leap 15.2 2. zypper in hawk2 3. zypper in ha-cluster-bootstrap 4. ha-cluster-init with the browser (from a Win 10 laptop) https://192.168.12.242:7630/ - get certificate error - accept BLANK white screen Actual Results: BLANK whit screen no HAWK2 login Expected Results: HAWK2 Login screen & HAWK 2 UI -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1178340] New: [yast] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)
by bugzilla_noreply＠suse.com 07 Feb '23

07 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1178340 Bug ID: 1178340 Summary: [yast] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jslaby(a)suse.com QA Contact: jsrain(a)suse.com CC: glin(a)suse.com, jens(a)krieger-juhnke.de, jlee(a)suse.com, jslaby(a)suse.com, mbenes(a)suse.com, mchang(a)suse.com, tiwai(a)suse.com Blocks: 1172292 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1172292 +++ On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium. ============= Could the installer detect whether firmware is 32 or 64 bit on x86_64 and install either grub2-i386-efi, or grub2-x86_64-efi respectively. This detection can be done by checking /sys/firmware/efi/fw_platform_size (it contains either 32 or 64). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1094961] New: Plymouth delays boot process or hangs
by bugzilla_noreply＠novell.com 07 Feb '23

07 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1094961 Bug ID: 1094961 Summary: Plymouth delays boot process or hangs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: cookie170(a)web.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Leap 15, fresh install on Lenovo Thinkpad T450s. Booting took at least a minute, Plymouth showing that moving symbol and eventually login screen appears. I added `plymouth.enable=0` to the boot parameters and now boot process only takes some seconds. /home is encrypted with LUKS, so I have to provide the PW. Plymouth seems to hang after this step. -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 1123960] New: LibreOffice missing libreoffice-gtk3
by bugzilla_noreply＠novell.com 06 Feb '23

06 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1123960 Bug ID: 1123960 Summary: LibreOffice missing libreoffice-gtk3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: LibreOffice Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: knurpht(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrading to TW 20190126, LO shows the Win95 like fallback interface. Knowing it is a gtk based app, I ran 'zypper se -i -v libreoffice' I noticed libreoffice-gtk3 was not installed, so as a try I installed that. LO back to normal after doing so. -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1188949] New: The wired connection stops connecting the next day after installation
by bugzilla_noreply＠suse.com 06 Feb '23

06 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1188949 Bug ID: 1188949 Summary: The wired connection stops connecting the next day after installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: vladislavmil(a)mail.ru QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 851456 --> http://bugzilla.opensuse.org/attachment.cgi?id=851456&action=edit NetworkManager logs, inxi-Fxz output, video and photo with error demonstration After installation, the wired connection works correctly. The next day, it stops connecting. There is a network connection that lasts indefinitely. Creating new connections does not lead to any result, as does trying to reconnect to an existing connection. It only helps to roll back the system to the backup created immediately after installation. The bug manifests itself on all DE and the next day after installation. During installation, the system configures the wired connection itself and the installation takes place without any errors. The problem manifests itself in openSUSE Leap and Tumbleweed, the wired connection works correctly on other distributions. I tried to install the r8168 driver, and add r8169 to the blacklist, but this does not help. Installing a third-party custom kernel also does not fix the problem. IPv4, IPv6, DNS and the default route disappear from the connection settings. I looked at the Network Manager configs, but there is nothing suspicious there, because of which the problem could manifest itself. -- You are receiving this mail because: You are on the CC list for the bug.

1 46

[Bug 1186027] New: VUL-1: CVE-2021-32917,CVE-2021-32918,CVE-2021-32919,CVE-2021-32920,CVE-2021-32921: Prosody XMPP server advisory 2021-05-12 (multiple vulnerabilities)
by bugzilla_noreply＠suse.com 05 Feb '23

05 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1186027 Bug ID: 1186027 Summary: VUL-1: CVE-2021-32917,CVE-2021-32918,CVE-2021-32919,CVE-2021- 32920,CVE-2021-32921: Prosody XMPP server advisory 2021-05-12 (multiple vulnerabilities) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other URL: https://smash.suse.de/issue/284222/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: mvetter(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- Prosody security advisory 2021-05-12 ==================================== Project : Prosody XMPP server URL : https://prosody.im/ Date : 2021-05-12 This advisory details 5 new security vulnerabilities discovered in the Prosody.im XMPP server software. All issues are fixed in the 0.11.9 release default configuration. **References** - Release announcement: https://blog.prosody.im/prosody-0.11.9-released/ - Advisory (HTML): https://prosody.im/security/advisory_20210512/ - Advisory (text): https://prosody.im/security/advisory_20210512.txt 1/5: DoS via insufficient memory consumption controls ----------------------------------------------------- CVE : CVE-2021-32918 CVSS : 7.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C) CWEs : CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that default settings leave Prosody susceptible to remote unauthenticated denial-of-service (DoS) attacks via memory exhaustion when running under Lua 5.2 or Lua 5.3. Lua 5.2 is the default and recommended Lua version for Prosody 0.11.x series. **Affected configurations** The default configuration is susceptible to this issue. Configurations with stricter settings for stanza size limits, rate limits and garbage collection parameters are at decreased risk from this attack. For more details please review the 'Mitigation' section for recommended values. **Mitigation** Mitigation is possible through configuration changes (on 0.11.7+). All the configuration changes described in this section are applied by default in Prosody 0.11.9. 1) Enable more aggressive garbage collection On Lua 5.2 and 5.3, the garbage collector does not free unused memory fast enough by default. This allowed Prosody's memory usage to grow excessively during certain traffic patterns. It is recommended to set a garbage collection speed of at least 500 in the global section of your configuration file: ``` gc = { speed = 500; } ``` Be aware that this setting may increase CPU usage if the other mitigations in this section are not applied. 2) Enable stricter stanza size limits By default Prosody ships with extremely permissive stanza size limits (up to 10MB). This value was introduced as a way to place a limit on memory usage without affecting legitimate use of the server. However testing demonstrates that the default limit is too high for most deployments. Our recommendation (and the default in 0.11.9) is to adopt the same default size limits that are already enforced by ejabberd, one of the other major XMPP servers on the network. To enable the new limits explicitly, add to the global section of your configuration file the following options: c2s_stanza_size_limit = 256 * 1024 s2s_stanza_size_limit = 512 * 1024 Be aware that reducing limits has the potential to introduce interoperability issues with deployments that do not enforce the same size limits. For example, remote contacts with large avatars. 3) Enable rate limits By default Prosody does not enable any rate limits. However we recommend enabling them for all production and public deployments to ensure fair consumption of resources across all connections. First, ensure that mod_limits is enabled by adding "limits" to your global modules_enabled configuration option: ``` modules_enabled = { ... "limits"; ... } ``` Next, configure the limits: ``` limits = { c2s = { rate = "10kb/s"; }; s2sin = { rate = "30kb/s"; } } ``` **Advice** All public deployments should upgrade to 0.11.9 or apply the above configuration changes. Deployments using nightly builds should upgrade to the latest available builds. **Credits** Many thanks to Travis Burtrum (moparisthebest) for discovering and reporting this issue, and providing a test case. **Commits** - https://hg.prosody.im/trunk/rev/db8e41eb6eff - https://hg.prosody.im/trunk/rev/b0d8920ed5e5 - https://hg.prosody.im/trunk/rev/929de6ade6b6 - https://hg.prosody.im/trunk/rev/63fd4c8465fb - https://hg.prosody.im/trunk/rev/1937b3c3efb5 - https://hg.prosody.im/trunk/rev/3413fea9e6db ---------------------------------------------------------------------------- 2/5: DoS via repeated TLS renegotiation causing excessive CPU consumption ---------------------------------------------------------------------------- CVE : CVE-2021-32920 CVSS : 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C) CWEs : CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that Prosody does not disable SSL/TLS renegotiation, even though this is not used in XMPP. A malicious client may flood a connection with renegotiation requests to consume excessive CPU resources on the server. Support for disabling renegotiation depends on OpenSSL 1.1.1+ and LuaSec 0.7+. **Affected configurations** The default configuration is susceptible to this issue. **Temporary mitigation** Ensure you have OpenSSL 1.1.1 or higher and LuaSec 0.7 or higher, and set the following ssl option (or add to your existing one if you have one): ``` ssl = { options = { no_renegotiation = true; } } ``` This configuration is applied by default in 0.11.9. **Advice** All public deployments should upgrade to 0.11.9 or apply the above configuration changes. Deployments using nightly builds should upgrade to the latest available builds. **Credits** This flaw was discovered by Kim Alvefur, a member of the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/55ef50d6cf65 - https://hg.prosody.im/trunk/rev/5a484bd050a7 - https://hg.prosody.im/trunk/rev/aaf9c6b6d18d ----------------------------------------------------------------------- 3/5: Use of timing-dependent string comparison with sensitive values ----------------------------------------------------------------------- CVE : CVE-2021-32921 CVSS : 4.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:U) CWEs : CWE-1254 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** It was discovered that Prosody does not use a constant-time algorithm for comparing certain secret strings when running under Lua 5.2 or later. This can potentially be used in a timing attack to reveal the contents of secret strings to an attacker. Lua 5.1 utilizes a technique called "string interning", which protected string comparisons from timing attacks. In Lua 5.2 and later versions, strings over 40 bytes in length are excluded from interning. With Prosody running under Lua 5.2, this makes any secret string over 40 bytes in length vulnerable to potential discovery via timing attacks. Note that if a secret string contains non-ASCII (unicode) characters, it may be longer than 40 bytes when encoded as UTF-8 (Prosody's internal encoding) even if it is fewer than 40 characters long. It should be noted that to successfully perform a timing attack, a significant number of failed attempts must typically be made to "guess" at the contents of the secret string. We are not aware of any attempts to exploit this vulnerability (which would likely be noticeable), and no known proof-of-concept exploit exists. **Affected configurations** This flaw affects the following modules: - mod_auth_internal_plain (disabled by default) mod_auth_internal_plain performs a timing-dependent comparison to the user's password if the user's password is longer than 40 bytes. This may allow an attacker to discover a user's password via a timing attack. We do not generally recommend mod_auth_internal_plain for new deployments, and mod_auth_internal_hashed has been the default for Prosody 0.11.x. - mod_muc (disabled by default) mod_muc supports password-protection of MUCs. The password validity check is performed using a timing-dependent comparison, which may allow an attacker to discover the MUC password via a timing attack if the password is longer than 40 bytes. We do not generally recommend using password-protected MUCs. Instead use affiliations to directly grant access to specific JIDs whenever possible. - mod_auth_internal_hashed (enabled by default but not typically vulnerable) mod_auth_internal_hashed has been updated for safety, but it is not vulnerable in the default configuration of Lua 5.2 as the password hashes it compares do not exceed 40 bytes. - mod_dialback (enabled by default but not typically vulnerable) mod_dialback has been updated for safety, but due to the single-use nature of s2s dialback verification strings a timing attack on this module is not believed to be possible, or to grant an attacker any advantage if it were. **Temporary mitigation** mod_auth_internal_plain: we recommend that people upgrade to mod_auth_internal_hashed due to this and also to benefit from its other security properties. mod_muc: use affiliations to grant access to a MUC instead of passwords. If passwords must be used, ensure they are shorter than 40 bytes. Rate limits can greatly lengthen the amount of time required to successfully complete a timing attack. Enable and configure mod_limits. **Advice** All deployments should upgrade to 0.11.9. Deployments using nightly builds should upgrade to the latest available builds. **Credits** This flaw was discovered by Matthew Wild, a member of the Prosody team. The issue with MUC passwords was also previously identified by Robert Gr��sser. **Commits** - https://hg.prosody.im/trunk/rev/c98aebe601f9 - https://hg.prosody.im/trunk/rev/13b84682518e - https://hg.prosody.im/trunk/rev/6f56170ea986 ------------------------------------------------------------------- 4/5: Use of mod_proxy65 is unrestricted in default configuration ------------------------------------------------------------------- CVE : CVE-2021-32917 CVSS : 5.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C) CWEs : CWE-862, CWE-400 Affected versions : All versions prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** mod_proxy65 is a file transfer proxy provided with Prosody to facilitate the transfer of files and other data between XMPP clients. It was discovered that the proxy65 component of Prosody allows open access by default, even if neither of the users have an XMPP account on the local server, allowing unrestricted use of the server's bandwidth. **Affected configurations** The default configuration does not enable mod_proxy65 and is not affected. With mod_proxy65 enabled, all configurations without a 'proxy65_acl' setting configured are affected. **Temporary mitigation** Configure 'proxy65_acl' to a list of XMPP domains that should be allowed to use the file transfer proxy. **Advice** All deployments should upgrade to 0.11.9 and/or configure a 'proxy65_acl' as desired. Deployments using nightly builds should upgrade to the latest available builds. The default behaviour in 0.11.9 allows all local clients to initiate a data stream through the proxy if proxy65_acl is unconfigured. **Credits** This flaw was discovered by the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/65dcc175ef5b -------------------------------------------------------------- 5/5: Undocumented dialback-without-dialback option insecure -------------------------------------------------------------- CVE : CVE-2021-32919 Affected versions : Prosody 0.10.x, Prosody 0.11.x prior to 0.11.9 Fixed versions : 0.11.9, 0.11 nightly build 130, trunk nightly build 1434 **Description** The undocumented option 'dialback_without_dialback' enabled an experimental feature for server-to-server authentication. A flaw in this feature meant it did not correctly authenticate remote servers, allowing a remote server to impersonate another server when this option is enabled. **Affected configurations** The default configuration is not affected. Configurations with the setting 'dialback_without_dialback' set to true are affected. **Temporary mitigation** Remove or disable the 'dialback_without_dialback' option. **Advice** All deployments should upgrade to 0.11.9 or disable this feature. Deployments using nightly builds should upgrade to the latest available builds. The affected feature has been removed in 0.11.9. **Credits** This flaw was discovered by the Prosody team. **Commits** - https://hg.prosody.im/trunk/rev/6be890ca492e - https://hg.prosody.im/trunk/rev/d0e9ffccdef9 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1182554] New: cannot start greetd.service .... missing PAM module
by bugzilla_noreply＠suse.com 02 Feb '23

02 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1182554 Bug ID: 1182554 Summary: cannot start greetd.service .... missing PAM module Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: mcepl(a)suse.com QA Contact: qa-bugs(a)suse.de CC: denis.kondratenko(a)suse.com, mcepl(a)suse.com, opensuse(a)trummer.xyz, stdden(a)opensuse.org Found By: --- Blocker: --- Created attachment 846366 --> https://bugzilla.suse.com/attachment.cgi?id=846366&action=edit journalctl -xb output When trying to replace gdm with greetd following the steps on https://en.opensuse.org/Portal:OpenSUSEway, greetd fails to start and journal shows: �no 22 09:38:10 stitny greetd[2347]: error: PAM 'greetd' service missing When looking around, there is the file /usr/etc/pam.d/greetd with this content: ~@stitny$ cat /usr/etc/pam.d/greetd #%PAM-1.0 auth requisite pam_nologin.so auth include common-auth account include common-account password include common-password session required pam_loginuid.so session optional pam_keyinit.so force revoke session include common-session ~@stitny$ but I have still /etc/pam.d/ as well and there is no greetd file. Which one is used? -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1165273] New: zathura-plugin-pdf-mupdf not loaded due to error.
by bugzilla_noreply＠novell.com 31 Jan '23

31 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1165273 Bug ID: 1165273 Summary: zathura-plugin-pdf-mupdf not loaded due to error. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dracaphallus(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36 Build Identifier: Running zathura after the installation of zathura-plugin-pdf-mupdf the following error output is produced: ``` error: Could not load plugin '/usr/lib64/zathura/libpdf-mupdf.so' (/usr/lib64/zathura/libpdf-mupdf.so: undefined symbol: jpeg_resync_to_restart). ``` >From the error output I'd deduced that the package was packaged wrong and therefore produced the error mentioned above. It has the plugin from working as intended by making zathura incapable of opening the supported document formats (PDF, ePub, and OpenXPS). This issue was reported 14 days ago using the comment section of openSUSE:Factory, while it was reported 8 days ago in the comment section of `X11:Utilities` with no response. This has lead me to file a bug report in OpenSUSE Bugzilla with the hope of getting this issue resolved. Reproducible: Always Steps to Reproduce: 1. Installing zathura-plugin-pdf-mupdf using zypper. 2. Running zathura through terminal. Actual Results: The following error was produced: ``` error: Could not load plugin '/usr/lib64/zathura/libpdf-mupdf.so' (/usr/lib64/zathura/libpdf-mupdf.so: undefined symbol: jpeg_resync_to_restart). ``` Expected Results: Zathura being able to open the supported document formats (PDF, ePub, and OpenXPS). -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1200564] New: io_uring instability on ppc64
by bugzilla_noreply＠suse.com 30 Jan '23

30 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1200564 Bug ID: 1200564 Summary: io_uring instability on ppc64 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: PowerPC-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- when using aio=io_uring in qemu for KVM virtual machine guests on a SLE15SP4 or a opensuse tumbleweed host kernel on power8 or power9 machine, we have very rapid I/O corruption (within milliseconds-seconds) in the guest. on all other architectures things work perfectly fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1195291] New: initrd is being rebuilt when kernel is being removed after kernel update
by bugzilla_noreply＠suse.com 28 Jan '23

28 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1195291 Bug ID: 1195291 Summary: initrd is being rebuilt when kernel is being removed after kernel update Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Despite of the problem that initrds are needlessy rebuilt when installing kernel modules (bug 1100885, bug 1191322), there are also needless rebuilds when removing obsolete kernels: Still on the next boot when older kernels are removed, their initrds are being rebuilt before the kernels are removed (it seems at least). Example (combining extracts from journal and /var/log/zypp/history): Jan 27 21:36:03 i7.site [RPM][7347]: install kernel-default-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:36:04 i7.site [RPM][17173]: erase kernel-macros-5.3.18-59.40.1.noarch: success Jan 27 21:36:05 i7.site [RPM][17173]: install kernel-macros-5.3.18-150300.59.43.1.noarch: success Jan 27 21:36:06 i7.site [RPM][17173]: erase kernel-macros-5.3.18-59.40.1.noarch: success Jan 27 21:36:06 i7.site [RPM][17173]: install kernel-macros-5.3.18-150300.59.43.1.noarch: success Jan 27 21:37:32 i7.site [RPM][17175]: install kernel-preempt-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:37:47 i7.site [RPM][27390]: install kernel-default-extra-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:37:55 i7.site [RPM][27492]: install kernel-devel-5.3.18-150300.59.43.1.noarch: success Jan 27 21:37:55 i7.site [RPM][27492]: install kernel-devel-5.3.18-150300.59.43.1.noarch: success Jan 27 21:38:03 i7.site [RPM][27497]: install kernel-preempt-extra-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:25 i7.site [RPM][27675]: install kernel-default-optional-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:28 i7.site [RPM][27776]: install kernel-preempt-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:28 i7.site [RPM][27776]: install kernel-preempt-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:31 i7.site [RPM][27782]: install kernel-default-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:31 i7.site [RPM][27782]: install kernel-default-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:37 i7.site [RPM][27788]: install kernel-preempt-optional-5.3.18-150300.59.43.1.x86_64: success # 2022-01-27 21:43:41 Output of kernel-default-extra-5.3.18-150300.59.43.1.x86_64.rpm %posttrans script: # Creating initrd: /boot/initrd-5.3.18-150300.59.43-default # Creating initrd: /boot/initrd-5.3.18-150300.59.43-preempt # Creating initrd: /boot/initrd-5.3.18-59.40-default # Creating initrd: /boot/initrd-5.3.18-59.40-preempt ### Reboot ### Jan 28 20:24:49 i7 zypper[1916]: The following 9 packages are going to be REMOVED: Jan 28 20:24:49 i7 zypper[1916]: kernel-default-5.3.18-59.37.2 kernel-default-devel-5.3.18-59.37.2 kernel-default-extra-5.3.18-59.37.2 kernel-default-optional-5.3.18-59.37.2 kernel-devel-5.3.18-59.37.2 kernel-preempt-5.3.18-59.37.2 kernel-preempt-devel-5.3.18-59.37.2 kernel-preempt-extra-5.3.18-59.37.2 kernel-preempt-optional-5.3.18-59.37.2 Jan 28 20:24:49 i7 zypper[1916]: 9 packages to remove. Jan 28 20:27:04 i7.site [RPM][2887]: erase kernel-default-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:27:07 i7.site [RPM][2887]: erase kernel-default-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:27:07 i7.site zypper[1916]: (1/9) Removing kernel-default-devel-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:27:08 i7.site [RPM][4137]: erase kernel-default-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:31:10 i7.site [RPM][4137]: erase kernel-default-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:31:10 i7.site zypper[1916]: (2/9) Removing kernel-default-optional-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:31:11 i7.site [RPM][11952]: erase kernel-preempt-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:31:20 i7.site [RPM][11952]: erase kernel-preempt-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:31:20 i7.site zypper[1916]: (3/9) Removing kernel-preempt-devel-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:31:20 i7.site [RPM][11958]: erase kernel-preempt-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:32:24 i7.site [RPM][11958]: erase kernel-preempt-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:32:24 i7.site zypper[1916]: (4/9) Removing kernel-preempt-optional-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:32:25 i7.site [RPM][19401]: erase kernel-default-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:33:13 i7.site [RPM][19401]: erase kernel-default-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:33:13 i7.site zypper[1916]: (5/9) Removing kernel-default-extra-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:33:13 i7.site zypper[1916]: Creating initrd: /boot/initrd-5.3.18-59.37-default # Creating initrd: /boot/initrd-5.3.18-59.37-default Jan 28 20:33:17 i7.site [RPM][26818]: erase kernel-devel-5.3.18-59.37.2.noarch: success Jan 28 20:33:24 i7.site [RPM][26818]: erase kernel-devel-5.3.18-59.37.2.noarch: success Jan 28 20:33:24 i7.site zypper[1916]: (6/9) Removing kernel-devel-5.3.18-59.37.2.noarch [.....done] Jan 28 20:33:24 i7.site [RPM][26819]: erase kernel-preempt-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:34:11 i7.site [RPM][26819]: erase kernel-preempt-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:34:11 i7.site zypper[1916]: (7/9) Removing kernel-preempt-extra-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:34:11 i7.site zypper[1916]: Creating initrd: /boot/initrd-5.3.18-59.37-preempt # Creating initrd: /boot/initrd-5.3.18-59.37-preempt Jan 28 20:34:12 i7.site [RPM][1784]: erase kernel-default-5.3.18-59.37.2.x86_64: success Jan 28 20:34:43 i7.site [RPM][1784]: erase kernel-default-5.3.18-59.37.2.x86_64: success Jan 28 20:34:43 i7.site zypper[1916]: (8/9) Removing kernel-default-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:34:44 i7.site [RPM][4725]: erase kernel-preempt-5.3.18-59.37.2.x86_64: success Jan 28 20:35:15 i7.site [RPM][4725]: erase kernel-preempt-5.3.18-59.37.2.x86_64: success Jan 28 20:35:15 i7.site zypper[1916]: (9/9) Removing kernel-preempt-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:35:15 i7.site systemd[1]: purge-kernels.service: Succeeded. In addition to rebuiling the initrds, the bootloader was reinstalled (including the os-prober), so the removal of the old kernels took 10 minutes alltogether! # grep run_command.*grub2 /var/log/pbl.log 2022-01-27 21:35:35 <1> update-bootloader-7882 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:36:03 <1> bootloader_entry-1449 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:37:03 <1> update-bootloader-9958 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:37:32 <1> bootloader_entry-8996 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:41:39 <1> update-bootloader-8968 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:42:20 <1> update-bootloader-0547 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:43:00 <1> update-bootloader-6949 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:43:41 <1> update-bootloader-7629 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:31:09 <1> update-bootloader-0043 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:32:23 <1> update-bootloader-4882 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:33:12 <1> update-bootloader-4790 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:34:11 <1> update-bootloader-4190 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:34:43 <1> bootloader_entry-0829 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:35:14 <1> bootloader_entry-7074 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: Reinstalling the boot loader 15 times when updating two kernels!? -- You are receiving this mail because: You are on the CC list for the bug.

1 13