[opensuse-factory] is Factory first still true for SLES code / Patches / fixes?
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: ---------------------------------------------------------------------- Thu Jan 24 10:18:23 UTC 2019 - Add:btmon: multiple memory management vulnerabilities fixed Multiple different memory management vulnerabilities were discovered in btmon while fuzzing it with American Fuzzy Lop. Purpose of this fuzzing effort was to find some bugs in btmon, analyse and fix them but also try to exploit them. Also goal was to prove that fuzzing is low effort way to find bugs that could end up being severe ones. Most common weakness appeared to be buffer over-read which was usually caused by missing boundary checks before accessing array. Integer underflows were also quite common. Most interesting bug was simple buffer overflow that was actually discovered already couple years ago by op7ic: https://www.spinics.net/lists/linux-bluetooth/msg68898.html but it was still not fixed. This particular vulnerability ended up being quite easily exploitable if certain mitigation technics were disabled.(bsc#1015173)(CVE-2016-9918)(bsc#1013893)(CVE-2016-9802) 0001-btmon-fix-segfault-caused-by-buffer-over-read.patch 0002-btmon-fix-segfault-caused-by-buffer-over-read.patch 0003-btmon-fix-segfault-caused-by-buffer-over-read.patch 0004-btmon-Fix-crash-caused-by-integer-underflow.patch 0005-btmon-fix-stack-buffer-overflow.patch 0006-btmon-fix-multiple-segfaults.patch 0007-btmon-fix-segfault-caused-by-integer-underflow.patch 0008-btmon-fix-segfault-caused-by-integer-undeflow.patch 0009-btmon-fix-segfault-caused-by-buffer-over-read.patch 0010-btmon-fix-segfault-caused-by-buffer-overflow.patch 0011-btmon-fix-segfault-caused-by-integer-underflow.patch 0012-btmon-fix-segfault-caused-by-buffer-over-read.patch ---------------------------------------------------------------------- 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 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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Nov 30, 2019 at 4:32 PM Stefan Seyfried
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:
---------------------------------------------------------------------- Thu Jan 24 10:18:23 UTC 2019
- Add:btmon: multiple memory management vulnerabilities fixed Multiple different memory management vulnerabilities were discovered in btmon while fuzzing it with American Fuzzy Lop. Purpose of this fuzzing effort was to find some bugs in btmon, analyse and fix them but also try to exploit them. Also goal was to prove that fuzzing is low effort way to find bugs that could end up being severe ones. Most common weakness appeared to be buffer over-read which was usually caused by missing boundary checks before accessing array. Integer underflows were also quite common. Most interesting bug was simple buffer overflow that was actually discovered already couple years ago by op7ic: https://www.spinics.net/lists/linux-bluetooth/msg68898.html but it was still not fixed. This particular vulnerability ended up being quite easily exploitable if certain mitigation technics were disabled.(bsc#1015173)(CVE-2016-9918)(bsc#1013893)(CVE-2016-9802) 0001-btmon-fix-segfault-caused-by-buffer-over-read.patch 0002-btmon-fix-segfault-caused-by-buffer-over-read.patch 0003-btmon-fix-segfault-caused-by-buffer-over-read.patch 0004-btmon-Fix-crash-caused-by-integer-underflow.patch 0005-btmon-fix-stack-buffer-overflow.patch 0006-btmon-fix-multiple-segfaults.patch 0007-btmon-fix-segfault-caused-by-integer-underflow.patch 0008-btmon-fix-segfault-caused-by-integer-undeflow.patch 0009-btmon-fix-segfault-caused-by-buffer-over-read.patch 0010-btmon-fix-segfault-caused-by-buffer-overflow.patch 0011-btmon-fix-segfault-caused-by-integer-underflow.patch 0012-btmon-fix-segfault-caused-by-buffer-over-read.patch ----------------------------------------------------------------------
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 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.
It is *definitely* still the policy. Unfortunately, I don't know if SUSE is doing anything right now to enforce it. Somebody definitely did something wrong here, as that should have been pushed into Factory first. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this.
It is *definitely* still the policy. Unfortunately, I don't know if SUSE is doing anything right now to enforce it. Somebody definitely did something wrong here, as that should have been pushed into Factory first.
Thanks for bringing this to my attention, Neal. Security issues are a bit special in that we strive to release fixes as quickly as possible (at the coordinated release date if applicable), which serially streaming *through* Factory first would not allow for. That said, even in such special cases such changes should go *to* Factory as quickly as possible. (I have not seen the distinction between "through Factory first" versus "to Factory as quickly as possible" formulated before, but hope it makes sense?) Gerald -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Nov 30, 2019 at 7:38 PM Gerald Pfeifer
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this.
It is *definitely* still the policy. Unfortunately, I don't know if SUSE is doing anything right now to enforce it. Somebody definitely did something wrong here, as that should have been pushed into Factory first.
Thanks for bringing this to my attention, Neal. Security issues are a bit special in that we strive to release fixes as quickly as possible (at the coordinated release date if applicable), which serially streaming *through* Factory first would not allow for. That said, even in such special cases such changes should go *to* Factory as quickly as possible.
(I have not seen the distinction between "through Factory first" versus "to Factory as quickly as possible" formulated before, but hope it makes sense?)
Something about that is a bit weird, though. In my experience with similar situations in Fedora + RHEL where I am the Fedora maintainer, I am usually added to the private bug for coordinating releasing fixes when Red Hat Product Security has to do this for RHEL and it's not already fixed in Fedora. This would allow both Fedora and RHEL to push the fix at the same time, satisfying issues like embargoes. I would have hoped there's a similar process in place for SUSE/openSUSE coordination. There's nothing that says we can't have SRs pushed to both Factory and SLE/Leap at the same time, and expedite them to be pushed and cycled through. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Nov 30, 2019 at 07:46:38PM -0500, Neal Gompa wrote:
Something about that is a bit weird, though. In my experience with similar situations in Fedora + RHEL where I am the Fedora maintainer, I am usually added to the private bug for coordinating releasing fixes when Red Hat Product Security has to do this for RHEL and it's not already fixed in Fedora. This would allow both Fedora and RHEL to push the fix at the same time, satisfying issues like embargoes. I would have hoped there's a similar process in place for SUSE/openSUSE coordination. There's nothing that says we can't have SRs pushed to both Factory and SLE/Leap at the same time, and expedite them to be pushed and cycled through.
I'm not sure if you are talking about security bugs in general or only about embargoed ones. Unless there is an embargo, our security bugs are public and embargoed ones are switched to public once the embargo is lifted. I certainly agree that if there is an external maintainer of the openSUSE package, he should be added to the bug when it's public. I don't know, however, if it's allowed to add external maintainers while the bug is still embargoed, that would be question for someone else who is more familiar with the conditions for the embargo. If not, external maintainer should be added when the bug goes public. There is also a technical problem that currently we cannot release openSUSE (no matter if Leap or Tumbleweed) updates as soon as the embargo is lifted even if the openSUSE maintainer is a SUSE employee. This is because the whole process for openSUSE is tied to (public) OBS and all of it (including openQA tests) expects to work with packages built there. Therefore we cannot even start the process before the embargo is lifted as that would require pushing the updated packages into OBS where anyone could see them. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-12-01 01:37, Gerald Pfeifer wrote:
Thanks for bringing this to my attention, Neal. Security issues are a bit special in that we strive to release fixes as quickly as possible (at the coordinated release date if applicable), which serially streaming *through* Factory first would not allow for. That said, even in such special cases such changes should go *to* Factory as quickly as possible.
(I have not seen the distinction between "through Factory first" versus "to Factory as quickly as possible" formulated before, but hope it makes sense?)
I'd say yes, because I can imagine that sometimes one goes for a different, maybe quickly hacked solution to avoid a security issue, while a better mid- or long-term solution is applied to Factory. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 01.12.19 um 01:37 schrieb Gerald Pfeifer:
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
OK.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this. To be fair, in this case the bug was originally filed against SLES12-SPx, and only later found to also affect SLES15, so maybe the assessment was "it will not affect Factory" Anyway, just CC'ing the openSUSE package maintainer on security bugs affecting a package might be a good way to get some attention.
*If* the openSUSE package maintainer thinks "I don't care for this old SLES stuff", then the removal of the CC in bugzilla is just one click away, but I guess most package maintainers at least care for the supported openSUSE releases. Have a nice weekend! -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-12-01 01:37, Gerald Pfeifer wrote:
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this.
It is *definitely* still the policy. Unfortunately, I don't know if SUSE is doing anything right now to enforce it. Somebody definitely did something wrong here, as that should have been pushed into Factory first.
Thanks for bringing this to my attention, Neal. Security issues are a bit special in that we strive to release fixes as quickly as possible (at the coordinated release date if applicable), which serially streaming *through* Factory first would not allow for. That said, even in such special cases such changes should go *to* Factory as quickly as possible.
(I have not seen the distinction between "through Factory first" versus "to Factory as quickly as possible" formulated before, but hope it makes sense?)
Gerald
As someone who, on occasion, has been required to get something into SLE "ASAP", on those occasions I took the care to send the internal SLE submission in parallel to the OBS Factory submission. I believe this is the most satisfactory compromise on "Factory first" for those occasions where something absolutely positively needs to be done in SLE/Leap at the fastest speed possible, while ensuring that Tumbleweed remains representative of the latest state of all of our codebases. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/12/2019 01.37, Gerald Pfeifer wrote:
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this.
It is *definitely* still the policy. Unfortunately, I don't know if SUSE is doing anything right now to enforce it. Somebody definitely did something wrong here, as that should have been pushed into Factory first.
Thanks for bringing this to my attention, Neal. Security issues are a bit special in that we strive to release fixes as quickly as possible (at the coordinated release date if applicable), which serially streaming *through* Factory first would not allow for. That said, even in such special cases such changes should go *to* Factory as quickly as possible.
(I have not seen the distinction between "through Factory first" versus "to Factory as quickly as possible" formulated before, but hope it makes sense?)
So far "Factory first" was in my experience mostly implemented as: Create a submit request to Factory before or together with a submit request to any other target product. Depending on the development project it can then make quite some difference where changes would be seen first. For new versions of SLE this means that maybe the next internal build has it before it was accepted into Factory which is normally not a problem but for it can also explain what you discussed above when it is relating to *security* related updates. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/1/19 11:07 AM, Gerald Pfeifer wrote:
On Sat 2019-11-30, Neal Gompa wrote:
On Sat, Nov 30, 2019 Stefan Seyfried wrote:
Is there still a "Factory first" policy for SLES?
Yes.
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.
Hmm; I just reached out to the SUSE security team and asked them to look into this.
As someone who regularly fixes critical embargoed security issues it is common practice to prepare a SLE update and ideally have it ready at the point when the embargo is lifted so we can ship already tested packages to customers / leap when the embargo is lifted. We can't fully prepare a submission for factory / tumbleweed until the embargo is lifted however, as open build service has no mechanism to make packages private. Further often packages are fixed differently between SLE/Leap and Tumbleweed, generally upstream will create a new release when security issues are fixed, our customers traditionally have a fear of updating to new releases so for SLE/Leap the update to fix the issue will generally contain patches that have been backported (with occasional exceptions). For Factory/Tumbleweed however, it almost always makes more sense to just take the new version. Often this means going through staging / reviews etc. For critical issues we will do our best to communicate with the release team / legal to make this process as quick as possible. But the key part of "Factory First" here is that the CVE's are fixed everywhere in some way not that the list of packages ends up the same. Although it seems in this case this process might not have worked correctly but i'll reply to Stefan's original email about that. -- 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
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
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? 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?
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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 02 Dec 2019 09:58:26 +0100, 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.
Yeah, that's the missing piece in the picture. Currently our security team puts SLE package maintainers to Cc to work on the reported security issues. This works mostly OK since each SLE package maintainer is supposed to be also a maintainer of Leap / FACTORY, too. However, it doesn't mean that they are the only maintainer of the package; there are external maintainers for some packages in OBS side like this case. So far, it's SLE package mainatiner's responsibility to extend the assignment or Cc to the external maintainers. But this doesn't work reliably at all, as it seems. I believe we should change the work flow a bit: let security team put *all* maintainers to Cc for bugs, but only public ones. That simple addition would make everyone happy. The original question -- whether the fix is immediately applied to FACTORY or not ("Factory first") -- this should still depend on the package maintainer, IMO. As long as the fixes are included in the upstream and a newer release is planned sooner or later, it's often not worth for extra patching, especially when the reported issues are trivial craps (as we've seen very frequently nowadays). Just my $0.02. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/2/19 10:35 AM, Takashi Iwai wrote:
The original question -- whether the fix is immediately applied to FACTORY or not ("Factory first") -- this should still depend on the package maintainer, IMO. As long as the fixes are included in the upstream and a newer release is planned sooner or later, it's often not worth for extra patching, especially when the reported issues are trivial craps (as we've seen very frequently nowadays).
Security problems should be fixed in Factory too as Tumbleweed is a supported distribution. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 02 Dec 2019 15:42:34 +0100, Adam Majer wrote:
On 12/2/19 10:35 AM, Takashi Iwai wrote:
The original question -- whether the fix is immediately applied to FACTORY or not ("Factory first") -- this should still depend on the package maintainer, IMO. As long as the fixes are included in the upstream and a newer release is planned sooner or later, it's often not worth for extra patching, especially when the reported issues are trivial craps (as we've seen very frequently nowadays).
Security problems should be fixed in Factory too as Tumbleweed is a supported distribution.
Yes, but it's a question of timing, too. If the upstream release including the fix is planned soon later, it's often even safer to wait for the upstream release for a while than immediately tweaking with own patches. That's why I mentioned that this decision should depend on the package maintainer: you always need to evaluate the risk. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On 12/2/19 9:58 AM, Stefan Seyfried wrote:
Am 02.12.19 um 09:48 schrieb Simon Lees:
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? 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.
I'm just going to echo something from internal discussion about the state of things. Our list of maintainers for packages is not exactly up-to-date. The one for internal build service is for employees and AFAIK security team will assign bugs based on this internal build service. The one of the external OBS instance, it's apparently not very well maintained. We have maintainers that are not maintainers anymore or ones that aren't active at all. And no one is really maintaining this list. I would say that you should contact the maintainer of this package (you already have the email address from the .changes file) to make sure that they add you to bugs in the future. Alternatively, you can *watch* the bugs from this user in Bugzilla yourself, https://bugzilla.suse.com/userprefs.cgi?tab=email just add the email address to the watch list. Then you will get notified of all bugs and you can then filter which ones are important for you or not (and which are open to community, but I think security incidents are not private unless there is an embargo and you would get email when that is lifted) Regarding your question if we have Factory-first policy -- yes. Packages that are sent from Factory to SLE are checked for missing bug references. If these are missing, new version of package can't get into SLE. So a package that is fixed in a Maintenance process needs to have these bugs sent to Factory before it can be updated. Maintainers that neglect this will cause a lot of unnecessary hurt for themselves in the future when the package needs to be updated in SLE. - Adam -- Adam Majer - amajer@suse.de SUSE Software Solutions Germany GmbH HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 2. Dezember 2019, 15:40:01 CET schrieb Adam Majer:
Alternatively, you can *watch* the bugs from this user in Bugzilla yourself,
https://bugzilla.suse.com/userprefs.cgi?tab=email
just add the email address to the watch list.
I remember that feature / input box on userprefs.cgi, but I can't see it anymore. Could it be that this feature was restricted to employees in the meantime? Regards, Christian Boltz -- * mrdocs wonders when darix sleeps <sshaw> mrdocs: robots don't need sleep [from #opensuse-buildservice] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Adam Majer -
Bernhard Voelker -
Christian Boltz -
Gerald Pfeifer -
Michal Kubecek -
Neal Gompa -
Oliver Kurz -
Richard Brown -
Simon Lees -
Stefan Seyfried -
Takashi Iwai