On 12/2/19 7:28 PM, Stefan Seyfried wrote:
Am 02.12.19 um 09:48 schrieb Simon Lees:
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.
There was no new version at that time. Just putting me into CC would have been totally sufficient. Or cloning the SLES bug for openSUSE and assigning to me.
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.
And why can't I be on the CC list of the SLE bug?
Provided there is no customer or embargod info in the bug there is no reason that you can't be, but this would generally be up to your co maintainer in most cases and it's clear they either do not understand the process here or have not done a good job on following through with it. This is a similar answer to most of your other questions
Why do i have to accidentally find this issue by reading Leap update notifications? Tumbleweed users are still affected by this issue today because of this.
One of the reasons is where Leap and SLE share packages they are unable to submit updates.
So why is the SLE maintainer not at least somehow mentioned in the openSUSE bluez package metadata?
A bug in process, i'll send the SUSE maintainer an email and get him in touch with you.
Due to various NDA arrangements etc the SUSE security team often can't disclose information about embargo'd bugs
Nothing embargoed in this case, the security issue was years old and public for a very long time.
Yep having now read the reports these issues were not considered that severe and were given a pretty low priority, still I believe the security team's approach for SLE packages is to assign the SLE maintainer and expect that they will fix it everywhere or work with the other maintainers to do so. -- 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