On 12/1/19 8:02 AM, Stefan Seyfried wrote:
Hi all,
see $SUBJECT. Is there still a "Factory first" policy for SLES?
The reason I'm asking is that I was surprised to find there is a bluez update for Leap 15.0 and 15.1 which comes from SLES15. I just found this by accident.
This section of the changelog would also have been relevant for Factory:
<Snip>
In January 2019, factory had still bluez version 5.50, these fixes went upstream only in version 5.51 which was released in September 2019 (and which did not yet make it to factory, but that's a different issue).
As I said in the other email, the key part of "Factory First" in relation to security issues is that CVE's fixed in SLE/Leap are also fixed in Tumbleweed, Often this may happen with backports on SLE because customers prefer that where as in tumbleweed it normally makes sense to take a new version.
As the bluez package maintainer, I would somehow expect to be on the CC list of bluez related security bugs reported on bugzilla and not having to discover them by accident.
Unfortunately a side effect of SLE and Leap sharing code is that community members can't be the sole maintainer of core SLE packages. One of the reasons is where Leap and SLE share packages they are unable to submit updates. The correct process here if a member of the community would like to help maintain the package (or already is the maintainer) then the SUSE employee should work with the community member to co maintain the package. From experience this has happened better in some teams then others possibly due to various communication issues. We did have a script that we ran occasionally to detect cases where this wasn't happening and address these issues, but it didn't show up much last time I should probably check it again to make sure it doesn't have bugs. Due to various NDA arrangements etc the SUSE security team often can't disclose information about embargo'd bugs to non SUSE employees as such these bugs are generally set to the bugowner listed in the internal build service rather then the one in openSUSE's. If the co maintenance is working well generally the other maintainers should be notified by the SUSE employee once the issue is public, but that is obviously not working in this case. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B