October 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1145193] activating chrony-wait.service by default delays booting without network for 10 minutes
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1145193 http://bugzilla.suse.com/show_bug.cgi?id=1145193#c68 --- Comment #68 from Lukas Ocilka <locilka(a)suse.com> --- OK, thanks for the clarification! Then we are on the same page :) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1148679] [Build 20190827] Broken yast command line tests
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1148679 http://bugzilla.suse.com/show_bug.cgi?id=1148679#c4 Joaquín Rivera <jeriveramoya(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jeriveramoya@suse | |.com) | --- Comment #4 from Joaquín Rivera <jeriveramoya(a)suse.com> --- I've just trigger new run and it still fails: https://openqa.opensuse.org/tests/1045425 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1151229] VUL-0: CVE-2019-13685,CVE-2019-13686,CVE-2019-13687,CVE-2019-13688: chromium: multiple use-after-free issues fixed in 77.0.3865.90
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1151229 http://bugzilla.suse.com/show_bug.cgi?id=1151229#c5 --- Comment #5 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-SU-2019:2228-1: An update that fixes four vulnerabilities is now available. Category: security (important) Bug References: 1151229 CVE References: CVE-2019-13685,CVE-2019-13686,CVE-2019-13687,CVE-2019-13688 Sources used: openSUSE Backports SLE-15 (src): chromium-77.0.3865.90-bp150.234.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1151229] VUL-0: CVE-2019-13685,CVE-2019-13686,CVE-2019-13687,CVE-2019-13688: chromium: multiple use-after-free issues fixed in 77.0.3865.90
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1151229 http://bugzilla.suse.com/show_bug.cgi?id=1151229#c4 --- Comment #4 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-SU-2019:2229-1: An update that fixes four vulnerabilities is now available. Category: security (important) Bug References: 1151229 CVE References: CVE-2019-13685,CVE-2019-13686,CVE-2019-13687,CVE-2019-13688 Sources used: openSUSE Backports SLE-15-SP1 (src): chromium-77.0.3865.90-bp151.3.15.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1145193] activating chrony-wait.service by default delays booting without network for 10 minutes
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1145193 http://bugzilla.suse.com/show_bug.cgi?id=1145193#c67 --- Comment #67 from Reinhard Max <max(a)suse.com> --- (In reply to Lukas Ocilka from comment #66) > (In reply to Reinhard Max from comment #65) > > enable it only on products that are usually not booted without network and > > have services that need precise time. > > Please, consider, that there is NOTHING like "products that usually..." > As openSUSE, SLES, SLED, you name it, are multi-purpose systems and the > Installer/YaST just can't define their major use-case and stick to that. Sorry, if my wording was not precise enough. With "products that usually..." I meant stuff like Kubic that according to Thorsten does absolutely not work with unsynchronised time. For such special-purpose products that have servces enabled by default which depend on precise time, I suggest to enable chrony-wait by default. But for the multi-purpose products you listed we should disable it by default for now and leave enabling up to the admins that install services that need it, as we had it before the change that broke booting on unnetworked laptops. > Moreover, any special handling based on the "current state", e.g. network > connection can change quite fast, especially for laptops. I totally agree and that's nothing I ever asked for. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1145193] activating chrony-wait.service by default delays booting without network for 10 minutes
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1145193 http://bugzilla.suse.com/show_bug.cgi?id=1145193#c66 --- Comment #66 from Lukas Ocilka <locilka(a)suse.com> --- (In reply to Reinhard Max from comment #65) > enable it only on products that are usually not booted without network and > have services that need precise time. Please, consider, that there is NOTHING like "products that usually..." As openSUSE, SLES, SLED, you name it, are multi-purpose systems and the Installer/YaST just can't define their major use-case and stick to that. Moreover, any special handling based on the "current state", e.g. network connection can change quite fast, especially for laptops. If it's too complicated then it's not worth implementing as it asks for bugs (undesired behavior in unknown use-cases) and would have to be changed later anyway. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1152596] New: improvement during network configuration
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1152596 Bug ID: 1152596 Summary: improvement during network configuration Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: All OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ivo.grimaldi(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello everyone I'm an admin of the Geekos Italia group on Telegram, a support group for openSUSE. We have see that, during the installation, most people do not compile the network section, they press "forward" "forward" "forward". In doing so, it does not correctly configure the network and at first reboot start by default wicked instead of Network Manager. we would like to suggest you to modify the defautl settings, so that they are a little clearer and that you can configure Network Manager. Thanks in advance for your prompt reply. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1151518] AUDIT-TRACKER: bluez: new D-Bus service /etc/dbus-1/system.d/bluetooth-mesh.conf
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1151518 http://bugzilla.suse.com/show_bug.cgi?id=1151518#c3 Matthias Gerstner <matthias.gerstner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1152672 Summary|AUDIT-0: bluez: new D-Bus |AUDIT-TRACKER: bluez: new |service |D-Bus service |/etc/dbus-1/system.d/blueto |/etc/dbus-1/system.d/blueto |oth-mesh.conf |oth-mesh.conf --- Comment #3 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- So I'm finished with the review. This new D-Bus service is quite a complex implementation. It provides a kind of bluetooth mesh networking stack to other users in the system via D-Bus. Applications can register themselves at the service and the service will in turn connect to a network application implemented on the users end of the D-Bus. This is quite a sensitive setup, since the privileged D-Bus service running as root now calls into an unprivileged D-Bus service running as a regular user. In bug 1152672 I've found a DoS vector that allows regular users to crash the mesh service running as root. Generally there's little isolation of different users of the bluetooth-mesh service against each other. For example user A may start a Join operation while an arbitrary other user B may cancel a join operation that is currently in progress. As an exception the Node1 interface is only accessible to the process that registered it in the first place. The Management1 interface allows regular users to create a lot of small files in /var/lib/bluetooth/mesh. Per network it's possible to allocate about 256 MiB of data for e.g. device keys so this has the potential to fill up /var. Also with this interface arbitrary users may add/delete/update network keys, device keys or app keys. Given that the mesh network is rather a niche feature I think doing an in-depth audit of this component isn't worth it. I don't feel very comfortable having such a complex service around, however, accessible to everybody. By default it's not autostarted, because the D-Bus config references an aliased systemd service that is only installed when the bluetooth-mesh service is enabled on systemd level. I would find it better to limit the D-Bus access to this mesh D-Bus service to members of a separate group. This would make it even more explicit and only allows users that actually want to work with mesh network to talk to the new service. Is there a suitable group already around that could be used for this? A patch of the D-Bus config will be necessary to implement it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1145193] activating chrony-wait.service by default delays booting without network for 10 minutes
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1145193 http://bugzilla.suse.com/show_bug.cgi?id=1145193#c65 Reinhard Max <max(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(max(a)suse.com) | --- Comment #65 from Reinhard Max <max(a)suse.com> --- (In reply to Josef Reidinger from comment #64) > Reinhard - I test potential change in yast with proposing to default ntp > server option "offline" which should mark source as offline and then network > dispatcher can activate it ( e.g. NM in > /etc/NetworkManager/dispatcher.d/20-chrony ). > But sadly it does not work and it still waiting when I am testing it > (instead of using rtc when all ntp servers are marked as offline). I wouldn't expected that to work, because when no ntp servers are reachable the clock is unsynchronized and hence chrony-wait waits. > Enabling chrony-wait based on availability of network is also tricky as e.g. > notebooks can have network when installed and then travelling without > network. Yes, I also won't recommend that. > So do you really see disabling chrony-wait as only option here for YaST how > to short-term fix it? Yes. > ( of course plan is that we add option to control.xml > if product require precise time and if so, then it will still enabled e.g. > for Kubic ). That's also only part of the workaround. It is services not products that require (or not) precise time, but until we have the dependencies sorted out to a point that we can enable chrony-wait unconditionally without blocking boot without network, it makes sense to enable it only on products that are usually not booted without network and have services that need precise time. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1145193] activating chrony-wait.service by default delays booting without network for 10 minutes
by bugzilla_noreply＠novell.com 01 Oct '19

01 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=1145193 http://bugzilla.suse.com/show_bug.cgi?id=1145193#c64 Josef Reidinger <jreidinger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(max(a)suse.com) --- Comment #64 from Josef Reidinger <jreidinger(a)suse.com> --- Reinhard - I test potential change in yast with proposing to default ntp server option "offline" which should mark source as offline and then network dispatcher can activate it ( e.g. NM in /etc/NetworkManager/dispatcher.d/20-chrony ). But sadly it does not work and it still waiting when I am testing it (instead of using rtc when all ntp servers are marked as offline). Enabling chrony-wait based on availability of network is also tricky as e.g. notebooks can have network when installed and then travelling without network. So do you really see disabling chrony-wait as only option here for YaST how to short-term fix it? ( of course plan is that we add option to control.xml if product require precise time and if so, then it will still enabled e.g. for Kubic ). -- You are receiving this mail because: You are on the CC list for the bug.

1 0