checkin bot that ensures bugzilla entries are actually readable?
Hi, some years later... I tried to read RPM changelogs and check what's changed, again. And, picking out 3 random checkins from opensuse-commit list with three random bsc#<number> numbers, I got three times the dreaded You are not authorized to access bug #<number>. Now we have lots of package-checkin-denying bots making a contributor's life hard. Couldn't we add another one that ensures there is a bugzilla entry that's actually readable as an prerequisite to checking in things to factory? As a deal, I would promise to stop complaining about the other bots ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thursday 2022-04-21 09:18, Stefan Seyfried wrote:
Now we have lots of package-checkin-denying bots making a contributor's life hard. Couldn't we add another one that ensures there is a bugzilla entry that's actually readable as an prerequisite to checking in things to factory? As a deal, I would promise to stop complaining about the other bots ;-)
github.com/openSUSE/openSUSE-release-tools , in there edit check_source.pl , take, for example, the patch name subcheck because that is one which analyses the .changes file in some form, check_source.pl:234: "A patch ($patch) is being added without this addition being mentioned in the changelog.\n" Then build the boo number check in a similar fashion to the for my $change (@changes) loop to grab a few bnc#/boo# links and curl-checking them. Deal? :) P.S.: Bugzilla does not support proper HTTP codes (Permission denied leads to HTTP 200 instead of HTTP 403). More stupid bugs to deal with, yay!
Hello, On 2022-04-21 09:18, Stefan Seyfried wrote:
Now we have lots of package-checkin-denying bots making a contributor's life hard. Couldn't we add another one that ensures there is a bugzilla entry that's actually readable as an prerequisite to checking in things to factory?
when this is a hard requirement for Factory checkin a prerequirement would be that every SUSE bug is public accessible (i.e. at least one comment of every SUSE bug must be public accessible). I guess this prerequirement is not yet fulfilled. I think for Leap such a requirement is impossible because basic Leap packages are maintained "inside SUSE" (i.e. those Leap packages that are inherited from SLE15) so SUSE internal bugs are normal as reference for Leap. Perhaps a more useful requirement in practice is that at least one of the mentioned URLs in a RPM changelog entry must be public accessible? So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug. Cf. https://en.opensuse.org/openSUSE:How_to_contribute_to_the_Printing_project ------------------------------------------------------------ The better your description of your change is (i.e. "what") and the easier it is to understand your explanation of the reason behind your change (i.e. "why") that you provide in the RPM changelog the more likely your change gets accepted ... "Bugfix for boo#1234 (upstream issue http://www.example.org/issue4567)" could be perfectly sufficient provided at least one of the openSUSE bug report and the upstream issue report is public accessible and tells about "what" and "why". ------------------------------------------------------------ Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On Thu, Apr 21, 2022 at 09:59:06AM +0200, Johannes Meixner wrote:
Hello,
On 2022-04-21 09:18, Stefan Seyfried wrote:
Now we have lots of package-checkin-denying bots making a contributor's life hard. Couldn't we add another one that ensures there is a bugzilla entry that's actually readable as an prerequisite to checking in things to factory?
when this is a hard requirement for Factory checkin a prerequirement would be that every SUSE bug is public accessible (i.e. at least one comment of every SUSE bug must be public accessible). I guess this prerequirement is not yet fulfilled.
I think for Leap such a requirement is impossible because basic Leap packages are maintained "inside SUSE" (i.e. those Leap packages that are inherited from SLE15) so SUSE internal bugs are normal as reference for Leap.
Perhaps a more useful requirement in practice is that at least one of the mentioned URLs in a RPM changelog entry must be public accessible?
So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug.
Cf. https://en.opensuse.org/openSUSE:How_to_contribute_to_the_Printing_project ------------------------------------------------------------ The better your description of your change is (i.e. "what") and the easier it is to understand your explanation of the reason behind your change (i.e. "why") that you provide in the RPM changelog the more likely your change gets accepted ... "Bugfix for boo#1234 (upstream issue http://www.example.org/issue4567)" could be perfectly sufficient provided at least one of the openSUSE bug report and the upstream issue report is public accessible and tells about "what" and "why". ------------------------------------------------------------
FWIW, Our CVE bugs are public accessible. There is now a PUBLIC SUSE Linux Enterprise 15 SPx product category in Bugzilla, where bugs either can be added or moved to. As usual, if a bug is from a customer making it public is hard due to the usual confidentiality / data protection rules. Ciao, Marcus
Hello, On 2022-04-21 10:03, Marcus Meissner wrote:
On Thu, Apr 21, 2022, Johannes Meixner wrote: ...
So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug. ... if a bug is from a customer making it public is hard due to the usual confidentiality / data protection rules.
that's what I meant with "bsc#98765432" in my example. I.e. when a customer reported a security issue we won't make his bug report public to not give foreigners any hint about his environment. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On 4/21/22 17:40, Johannes Meixner wrote:
Hello,
On 2022-04-21 10:03, Marcus Meissner wrote:
On Thu, Apr 21, 2022, Johannes Meixner wrote: ...
So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug. ... if a bug is from a customer making it public is hard due to the usual confidentiality / data protection rules.
that's what I meant with "bsc#98765432" in my example. I.e. when a customer reported a security issue we won't make his bug report public to not give foreigners any hint about his environment.
Security bugs are not the issue here, the security team does a really good job of making sure all security bugs end up public. The issue here is when a customer creates an L3 bug report, often there is customer info in places where we simply can't hide and our current policy is not to make a second "public" version of the ticket. Another issue in the past was that by default all SLE beta issues were created as private which is something that is being addressed and should improve into the future. -- 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
Hello, On 2022-04-21 11:00, Simon Lees wrote:
On 4/21/22 17:40, Johannes Meixner wrote:
On 2022-04-21 10:03, Marcus Meissner wrote:
On Thu, Apr 21, 2022, Johannes Meixner wrote: ...
So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug. ... if a bug is from a customer making it public is hard due to the usual confidentiality / data protection rules.
that's what I meant with "bsc#98765432" in my example. I.e. when a customer reported a security issue we won't make his bug report public to not give foreigners any hint about his environment.
Security bugs are not the issue here, the security team does a really good job of making sure all security bugs end up public. The issue here is when a customer creates an L3 bug report, often there is customer info in places where we simply can't hide and our current policy is not to make a second "public" version of the ticket.
Ah! So what happens when a customer reported a security issue as L3 bug report with customer internal info as usual? Then the security team does a really good job of making sure that L3 bug report ends up public? Likely it is too risky and too complicated to hide all bug entries that contain customer internal info from the public. So I guess a separated security bug report may be created together with a public new CVE issue. Then the RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (boo#789 bsc#456) ---------------------------------------------------------- where boo#789 is the public openSUSE security bug report and bsc#456 is the SUSE internal L3 bug report. The initial proposal wants that bsc#456 is public and my argument was that this is not possible. I wonder why we are now talking about details (triggered by my simple initial offhanded example) how and when which kind of SUSE internal things (there are also other SUSE internal things that are no SUSE bugzilla issues) are made public under which specific circumstances and who does what really good job instead of discussing the initial proposal? Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
On 4/21/22 19:10, Johannes Meixner wrote:
Hello,
On 2022-04-21 11:00, Simon Lees wrote:
On 4/21/22 17:40, Johannes Meixner wrote:
On 2022-04-21 10:03, Marcus Meissner wrote:
On Thu, Apr 21, 2022, Johannes Meixner wrote: ...
So a valid RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (bsc#98765432) ---------------------------------------------------------- where CVE-1234-56789 is public accessible but bsc#98765432 is a SUSE internal bug. ... if a bug is from a customer making it public is hard due to the usual confidentiality / data protection rules.
that's what I meant with "bsc#98765432" in my example. I.e. when a customer reported a security issue we won't make his bug report public to not give foreigners any hint about his environment.
Security bugs are not the issue here, the security team does a really good job of making sure all security bugs end up public. The issue here is when a customer creates an L3 bug report, often there is customer info in places where we simply can't hide and our current policy is not to make a second "public" version of the ticket.
Ah! So what happens when a customer reported a security issue as L3 bug report with customer internal info as usual?
Normally it gets marked as a duplicate. The security team has a semi automated process for finding and creating security bugs for anything that has a CVE / is reporting to one of our upstreams.
Then the security team does a really good job of making sure that L3 bug report ends up public? Likely it is too risky and too complicated to hide all bug entries that contain customer internal info from the public. So I guess a separated security bug report may be created together with a public new CVE issue. Then the RPM changelog entry could be something like ---------------------------------------------------------- - Security fix for ... CVE-1234-56789 (boo#789 bsc#456) ---------------------------------------------------------- where boo#789 is the public openSUSE security bug report and bsc#456 is the SUSE internal L3 bug report.
This is pretty much what happens already except its a shared SUSE security bug. Sometimes we also get alot of L3 enquires about a security issue and don't put them all in the changes file.
The initial proposal wants that bsc#456 is public and my argument was that this is not possible.
Yes I agree this is not possible for all bugs, and that one solution could be to get L3 to create a duplicate private bug but that's more work for them (and maintainers) that they would have to agree with.
I wonder why we are now talking about details (triggered by my simple initial offhanded example) how and when which kind of SUSE internal things (there are also other SUSE internal things that are no SUSE bugzilla issues) are made public under which specific circumstances and who does what really good job instead of discussing the initial proposal?
I spent significant amounts of time looking at this topic while I was on the board, in that time I found that the security team already do best possible practice in this area (while there are many others that certainly could be better, and some that are being improved). As such I wanted to acknowledge that the security team actually already does a really good job and they deserve some credit for 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
participants (5)
-
Jan Engelhardt -
Johannes Meixner -
Marcus Meissner -
Simon Lees -
Stefan Seyfried