openSUSE Bugs February 2021

bugs@lists.opensuse.org

1 participants
3246 discussions

[Bug 993885] New: Kde-Live net installer does not reboot after installation

by bugzilla_noreply＠novell.com

http://bugzilla.suse.com/show_bug.cgi?id=993885 Bug ID: 993885 Summary: Kde-Live net installer does not reboot after installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Live Medium Assignee: fvogt(a)suse.com Reporter: okurz(a)suse.com QA Contact: okurz(a)suse.com Found By: --- Blocker: --- ## observation Continuing through the whole installation process of the NET installer on the Kde-Live medium until the "reboot now" dialog shows up works fine but the reboot does not seem to happen ## steps to reproduce I am in the process of automating this but it can be as easy as * start Kde-Live * call installation from within plasma session * let installer run into "reboot now" action * observe that the system does not reboot ## expected result system should reboot into installed system ## workaround manual reboot of the system yields a properly setup Tumbleweed installation so the installation is ok. -- You are receiving this mail because: You are on the CC list for the bug.

1 hour, 35 minutes

[Bug 1097779] New: VUL-0: CVE-2018-12434: LibreSSL before 2.6.5 and 2.7.x before 2.7.4 allows a memory-cache side-channelattack on DSA and ECDSA signatures, aka the Return Of the Hidden Number Problemor ROHNP. To discover a key, the attacker needs access to

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1097779 Bug ID: 1097779 Summary: VUL-0: CVE-2018-12434: LibreSSL before 2.6.5 and 2.7.x before 2.7.4 allows a memory-cache side-channelattack on DSA and ECDSA signatures, aka the Return Of the Hidden Number Problemor ROHNP. To discover a key, the attacker needs access to Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://smash.suse.de/issue/208302/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: jengelh(a)inai.de Reporter: meissner(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2018-12434 LibreSSL before 2.6.5 and 2.7.x before 2.7.4 allows a memory-cache side-channel attack on DSA and ECDSA signatures, aka the Return Of the Hidden Number Problem or ROHNP. To discover a key, the attacker needs access to either the local machine or a different virtual machine on the same physical host. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-12434 https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.7.4-relnotes.txt https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.6.5-relnotes.txt -- You are receiving this mail because: You are on the CC list for the bug.

4 hours, 59 minutes

[Bug 1086778] New: VUL-0: CVE-2018-8970: libressl: The int_x509_param_set_hosts function in lib/libcrypto/x509/x509_vpm.c inLibreSSL 2.7.0 before 2.7.1 does not support a certain special case of a zeroname length, which causes silent omission of hostname verification

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1086778 Bug ID: 1086778 Summary: VUL-0: CVE-2018-8970: libressl: The int_x509_param_set_hosts function in lib/libcrypto/x509/x509_vpm.c inLibreSSL 2.7.0 before 2.7.1 does not support a certain special case of a zeroname length, which causes silent omission of hostname verification Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://smash.suse.de/issue/202623/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: meissner(a)suse.com QA Contact: security-team(a)suse.de CC: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2018-8970 The int_x509_param_set_hosts function in lib/libcrypto/x509/x509_vpm.c in LibreSSL 2.7.0 before 2.7.1 does not support a certain special case of a zero name length, which causes silent omission of hostname verification, and consequently allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate. NOTE: the LibreSSL documentation indicates that this special case is supported, but the BoringSSL documentation does not. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-8970 http://www.cvedetails.com/cve/CVE-2018-8970/ https://boringssl.googlesource.com/boringssl/+/e759a9cd84198613199259dbed40… https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.7.1-relnotes.txt https://github.com/libressl-portable/openbsd/commit/0654414afcce51a16d35d05… -- You are receiving this mail because: You are on the CC list for the bug.

4 hours, 59 minutes

[Bug 981004] New: Ensure template unit instances are deleted

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=981004 Bug ID: 981004 Summary: Ensure template unit instances are deleted Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Linux Status: NEW Severity: Enhancement Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: jengelh(a)inai.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When a package is uninstalled, it will also be removed from the boot sequence, by means of %preun generally calling %service_del_preun foo.service, which expands to (among other things) `systemctl disable foo.service`. To disable template instances such as foo(a)bar.service and foo(a)baz.service, one can - and must, since "bar" and "baz" are not known at any time to the package management system - use `systemctl disable foo@.service`, which will disable all instances. A number of packages are lacking the corresponding %service_del_preun template@.service lines, which means template instance links like foo(a)bar.service will stick around after package uninstall. 389-ds apache2 arpwatch autossh booth chrony cups device-mapper dracut envoy freeipa govpn gpsd kmscon libteam lvm2 lvm2-clvm mariadb mdadm mgetty mysql mysql-community-server openct openvpn parkverbot rear redis rfkill syncthing system-config-printer systemd systemd-mini tomcat vpnc vsftpd wicked xf86-input-wacom -- You are receiving this mail because: You are on the CC list for the bug.

6 hours, 20 minutes

[Bug 1171321] New: nftables crashes when trying to add rule to nonexistant chain

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1171321 Bug ID: 1171321 Summary: nftables crashes when trying to add rule to nonexistant chain Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Core was generated by `nft add rule inet traffic-filter input tcp dport { 22, 80, 443 } accept'. Program terminated with signal SIGSEGV, Segmentation fault. #0 erec_print (octx=octx@entry=0x55776a4222c0, erec=erec@entry=0x55776a425780, debug_mask=debug_mask@entry=0) at ../../src/erec.c:95 95 switch (indesc->type) { (gdb) bt #0 erec_print (octx=octx@entry=0x55776a4222c0, erec=erec@entry=0x55776a425780, debug_mask=debug_mask@entry=0) at ../../src/erec.c:95 #1 0x00007f0eadab847a in erec_print_list (octx=octx@entry=0x55776a4222c0, list=list@entry=0x7ffd930c3ff0, debug_mask=0) at ../../src/erec.c:190 #2 0x00007f0eadac2915 in nft_run_cmd_from_buffer (nft=0x55776a4222a0, buf=<optimized out>) at ../../src/libnftables.c:459 #3 0x0000557769ea68a3 in main (argc=14, argv=<optimized out>) at ../../src/main.c:453 (gdb) l 90 char *pbuf = NULL; 91 unsigned int i, end; 92 FILE *f; 93 int l; 94 95 switch (indesc->type) { 96 case INDESC_BUFFER: 97 case INDESC_CLI: 98 line = indesc->data; 99 *strchrnul(line, '\n') = '\0'; (gdb) p indesc $1 = (const struct input_descriptor *) 0x0 (gdb) quit -- You are receiving this mail because: You are on the CC list for the bug.

6 hours, 22 minutes

[Bug 1133222] New: openSUSE:Leap:15.1/hdf5:gnu-mpich-hpc failed

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1133222 Bug ID: 1133222 Summary: openSUSE:Leap:15.1/hdf5:gnu-mpich-hpc failed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other URL: https://build.opensuse.org/package/live_build_log/open SUSE:Leap:15.1/hdf5:gnu-mpich-hpc/standard/x86_64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: eich(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: adrian(a)suse.com Found By: --- Blocker: --- openSUSE:Leap:15.1/hdf5:gnu-mpich-hpc failed to build. Please see build log: https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.1/hdf5:g… The job repeatedly gets stuck in [ 2513s] Testing t_cache_image -- You are receiving this mail because: You are on the CC list for the bug.

18 hours, 59 minutes

[Bug 1153847] New: Unable to boot with SecureBoot enabled in BIOS

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1153847 Bug ID: 1153847 Summary: Unable to boot with SecureBoot enabled in BIOS Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: imax(a)posteo.org QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I'm unable to do a fresh tumbleweed install with SecureBoot enabled. After selecting usb device in boot menu i get a black screen not responding anymore. Pushing Esc after some time leads to an error message with system freeze: Failed to load image: Security Policy Violation When i disable SecureBoot i can boot fine.To exclude possible mistakes: - USB installer created with SUSE ImageWriter - Checksums are all fine - selected right entry in boot menu to boot usb-stick in UEFI mode Other distro's (Ubuntu, Debian, Fedora) officially supporting SecureBoot are working fine out of the box with SecureBoot enabled. With Leap i get the same behavior as described above. Is there something wrong with the signatures? regards -- You are receiving this mail because: You are on the CC list for the bug.

1 day, 19 hours

[Bug 1131686] New: openSUSE-2019-1163 security update for ldb break sssd

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1131686 Bug ID: 1131686 Summary: openSUSE-2019-1163 security update for ldb break sssd Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: 64bit OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Samba Assignee: samba-maintainers(a)SuSE.de Reporter: pellice(a)gmail.com QA Contact: samba-maintainers(a)SuSE.de Found By: --- Blocker: --- After I applied the openSUSE-2019-1163 security update for ldb sssd service crash at startup: sssd[15186]:ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.2.4 module_version=1.2.3 sssd[15186]: ldb: failed to initialise module /usr/lib64/ldb/samba/acl.so : Unavailable sssd[15186]: ldb: failed to initialise module /usr/lib64/ldb/samba : Unavailable sssd: SSSD couldn't load the configuration database [5]: Input/output error. I reverted it to previous version as a temporary workaround: zypper in --oldpackage libldb1-1.2.3-lp150.2.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

2 days, 9 hours

[Bug 1131754] New: sssd fails to start due to a ldb module version mismatch (after installing updates on 2019-04-05)

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1131754 Bug ID: 1131754 Summary: sssd fails to start due to a ldb module version mismatch (after installing updates on 2019-04-05) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Critical Priority: P5 - None Component: Samba Assignee: samba-maintainers(a)SuSE.de Reporter: mhupfer(a)franken-online.de QA Contact: samba-maintainers(a)SuSE.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build Identifier: # rcsssd status * sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2019-04-06 11:23:34 CEST; 17min ago Process: 4985 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4) Main PID: 4985 (code=exited, status=4) Apr 06 11:23:34 pcito20.leistritz.de systemd[1]: Starting System Security Services Daemon... Apr 06 11:23:34 pcito20.leistritz.de sssd[4985]: ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.2.4 module_version=1.2.3 Apr 06 11:23:34 pcito20.leistritz.de sssd[4985]: ldb: failed to initialise module /usr/lib64/ldb/samba/acl.so : Unavailable Apr 06 11:23:34 pcito20.leistritz.de sssd[4985]: ldb: failed to initialise module /usr/lib64/ldb/samba : Unavailable Apr 06 11:23:34 pcito20.leistritz.de sssd[4985]: SSSD couldn't load the configuration database [5]: Input/output error. Apr 06 11:23:34 pcito20.leistritz.de systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION Apr 06 11:23:34 pcito20.leistritz.de systemd[1]: Failed to start System Security Services Daemon. Apr 06 11:23:34 pcito20.leistritz.de systemd[1]: sssd.service: Unit entered failed state. Apr 06 11:23:34 pcito20.leistritz.de systemd[1]: sssd.service: Failed with result 'exit-code'. Reproducible: Always Steps to Reproduce: 1. zypper up 2. reboot 3. verify sssd status Actual Results: sssd fails to start, domain users cannot log on! Expected Results: sssd starts successfully as it did before the update on Friday, April 5. Previous "zypper up" run was roughly one week before. -- You are receiving this mail because: You are on the CC list for the bug.

2 days, 9 hours

[Bug 1173619] New: VUL-0: unbound: LPE from unbound to root

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1173619 Bug ID: 1173619 Summary: VUL-0: unbound: LPE from unbound to root Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: darin(a)darins.net Reporter: wolfgang.frisch(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- via security(a)suse.de: I believe to have found a configuration issue in the Unbound package. Or, depending on how you look at it, in the Unbound server itself. 1. Before starting the Unbound server, systemd routinely runs unbound-anchor. From 'systemctl cat unbound': ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem As you can see this process is run as user unbound. 2. The Unbound server writes a pid file before dropping privileges, i.e. as root. It then chown's the file in a second step. 'grep username /etc/unbound/unbound.conf': username: "unbound" And from the Unbound source: https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f… As you can see in the source, Unbound doesn't check if there is already a symbolic link in place of the pid file. 3. openSUSE configures Unbound to create the pid file in a directory owned by the unbound user. 'grep pidfile /etc/unbound/unbound.conf': pidfile: "/var/run/unbound/unbound.pid" 'cat /usr/lib/tmpfiles.d/unbound.conf': D /run/unbound 0755 unbound unbound - 4. unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool. But if it is compromised, and as it has write permission in the pid file directory and reliably runs before the server, an attacker could easily gain full root privileges by just creating a symbolic link /run/unbound/unbound.pid. 5. IMHO this would be best fixed in openSUSE by creating a root owned /run/unbound directory, or changing the pid file path to /run/unbound.pid or something like that. I think this would have the added advantage that openSUSE could ship and maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu: https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/us… With the current openSUSE setup there is the problem that if AppArmor filters CAP_DAC_OVERRIDE, Unbound has no permission to create a pid file in /run/unbound anymore. If you have questions please don't hesitate to contact me. Thanks for taking a look. Kind regards, Detlef -- You are receiving this mail because: You are on the CC list for the bug.

3 days, 4 hours

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs February 2021