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.
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-12434https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.7.4-relnotes.txthttps://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.
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.
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.
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.
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.
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.
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.
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.