Quoting Tomáš Chvátal :

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).

Your actions if cases like this happen are quite simple: 1) make the initial bug visible and mark the internal comments as internal. 2) if not sure ask somebody who knows more to do it for you.

As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.

So as a consequence I can no longer submit a security fix to address a 'non-public vulnurability' before opening the bug and making it public? :) This is probably about the only case where this makes sense anyway.. and the 'checking full logs' might hit a lot of people... especially 'us' community members.. we are very well capable to forwarding an SR, maintaining a full package, but we are typically also the ones blocked out from the non-visible bugs... I hope this won't result in a big chain where community packagers have a hard time getting old packages forwarded. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 21, Tomáš Chvátal wrote:

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE). Please think first about the consequences of such changes, and if this is really what you want to archive. Not everything which sounds good will have a positive effect in the end. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dne Čt 21. listopadu 2013 15:59:53, Tomáš Chvátal napsal(a): Just to note I wrote mine concenrs to the issue on progress too. So please respond with your why-is-it-bad there to convince Ludwig. I really didn't like the idea too :P just look how long it took me to do something about it. Tom

On Thu, Nov 21, Claudio Freire wrote:

On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk wrote:

...

On Thu, Nov 21, Tomáš Chvátal wrote:

...

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).

No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.

Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.

I wrote "we are not allowed" and I mean it that way. Even for the openSUSE community we cannot break laws and contracts. Creating dummy bugs without any information doesn't help, this is the same information as without bnc or with one not everybody can read. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi Claudio, On Nov 21, 13 13:53:40 -0200, Claudio Freire wrote:

On Thu, Nov 21, 2013 at 12:23 PM, Thorsten Kukuk wrote:

...

On Thu, Nov 21, Tomáš Chvátal wrote:

...

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).

No, only sensitive private information should be marked private, and the bug report itself, or at least the non-sensitive bits, should be left open for all to see.

This is not only about private comments. It's about a complete bug that may not be visible as a whole - because they contain sensitive information, NDAed information or are for a product where the bugs are not publicly available by default.

Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.

You are aware that we are talking about thousands of bugreports in the worst case? This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more. Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left. I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless). You are just taking information for some people away. Stefan -- Stefan Behlert, SUSE LINUX Project Manager Enterprise Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert wrote:

...

Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.

You are aware that we are talking about thousands of bugreports in the worst case?

No, I do not have SUSE stats.

This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.

Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.

Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.

I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).

You are just taking information for some people away.

It is really really wrong to reference a bnc by number on a changelog when that bnc is private. It adds obscurity into the community and that's bad. I agree that automatically checking and giving no exception mechanism puts SUSE employees in a position where they will probably choose to not a) push the change into openSuse, or b) reference the bug at all, and that's also bad. But lets not forget that adding obscure changelogs *is* *quite* *bad* in open source. So, what do you propose? What *can* SUSE employees do to improve that situation? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/21/2013 09:59 AM, Tomáš Chvátal wrote:

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P).

Your actions if cases like this happen are quite simple: 1) make the initial bug visible and mark the internal comments as internal. 2) if not sure ask somebody who knows more to do it for you.

As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody.

Replying to the original post, but considering comments made in subsequent posts. It is very easy to sympathize with and understand the desire to have bug reports accessible by community contributors that do not happen to work for SUSE to understand implemented fixes referenced in changelogs. This should be our premise going forward. However, implementing this retroactively is a problem as this has not been common practice. The problems of applying this wholesale have been outlined by others in this thread. Also as commented by others this creates a potentially very large work load plus chances where progress may be impeded. For example, a contributor applying an update or a fix to a specific package may be blocked from submitting the changes because the new changelog checks my block the submission based on a referenced bug number that is not accessible to the contributor. Now the contributor has a lot of extra work of chasing down the necessary help. On the other side having people that work with sensitive data create "sanitized" bug reports for all existing sensitive bugs creates a lot of work that is very unlikely to get done. However, I believe there is a way forward, and here is my proposal: 1.) Modify bugzilla such that the initial description cannot be marked as "Private". + This ensures, so one would hope, no sensitive data will be posted to the initial description + This also ensures that going forward bugs are public 2.) Modify the check script to take the date of submission into account. + changelog entries are dated and the checker should be able to ignore checks for bnc# referenced prior to a certain date This proposal provides the information contributors need on a going forward basis. I realize that we are still left with debt based on past practices, but in reality that debt is not going to get cleaned up, thus we might as well ignore it. Additionally the proposal allows things that are in the past, when the practices were different, to remain in the past. Some information is not accessible, that's unfortunate, but again this is very unlikely to change even if we try to enforce openness for the past. Last but not least the proposal establishes a new practice going forward. If followed consistently, the past practice will be less and less relevant in the future. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 21.11.2013 16:23, Thorsten Kukuk wrote:

On Thu, Nov 21, Tomáš Chvátal wrote:

...

Hello guys,

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

Ok, and since we are not allowed to make nearly all of this bugs public, it will end in either removing the bnc numbers (not good) or not submitting this fixes to openSUSE at all (very bad for openSUSE).

Please think first about the consequences of such changes, and if this is really what you want to archive. Not everything which sounds good will have a positive effect in the end. I rejected the pull request and factory-auto will stay as it is. I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.

Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/22/2013 08:40 AM, Stephan Kulow wrote:

I rejected the pull request and factory-auto will stay as it is. I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.

Coolo, I like your idea, this would be good. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 22 November 2013, Stefan Behlert wrote:

Moin,

On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:

...

On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert wrote:

...

...

Or... just file a new bnc with the non-sensitive description, a link to the private bnc, and add that to the changelog.

You are aware that we are talking about thousands of bugreports in the worst case?

No, I do not have SUSE stats.

...

This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.

Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.

Which could (and should) be added to the changelog then - not in a new bug. In my opinion.

...

...

Just to make this clear: Yes, we try to file as many bugs against openSUSE as possible, but there are still a lot left.

I wonder what is planned to achieve with that checking? You are not gaining any more information, as I doubt that a lot of people would really duplicate a (closed) security bug and strip of all related information (which btw makes the duplication worthless).

You are just taking information for some people away.

It is really really wrong to reference a bnc by number on a changelog when that bnc is private. It adds obscurity into the community and that's bad.

I agree with you in general, but I think it's worse to NOT have it referenced. And my fear (and from some past experiences I think it's a realistic fear) it will not end with people duplicating bug reports.

...

I agree that automatically checking and giving no exception mechanism puts SUSE employees in a position where they will probably choose to not a) push the change into openSuse, or b) reference the bug at all, and that's also bad.

But lets not forget that adding obscure changelogs *is* *quite* *bad* in open source.

I think if the short description in the changelog is "obscure", it's not because of the bugnumber ;) Realistically, if the changelog is good, how many people check all the bugnumbers?

Packagers are doing it. If you read patch-xyz has been added because of bnc1234 then 1234 must be public.

(Note: In an enterprise world the number here is 100% or close to, but I have my doubts that in openSUSE this is identical. But I have no numbers, so feel free to correct me.)

...

So, what do you propose? What *can* SUSE employees do to improve that situation?

My suggestion is to NOT change the current behavior, but put more emphasis on good changelog texts.

You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.

Maybe a warning to the submitter is the best choice, so that he or she can check and (if possible) adjust the state of the bug?

I am not claiming to have a solution, though :( My goal is to avoid disadvantages for openSUSE, as I think that all products will suffer - openSUSE as well as the Enterprise, as it could result in the loss of synergies.

Just kick out that closed bug numbers. It makes no sense that 99% of the ones who read it can't access it. I would rather support to add chinese text to the changelog than keeping these annyoing "dead links". cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/22/2013 03:00 PM, Ruediger Meier wrote:

On Thursday 21 November 2013, Adrian Schröter wrote:

...

Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:

...

On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert wrote:

..

...

...

This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.

Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.

True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.

If that description is not good enough openSUSE-Factory maintainers can of course reject the package.

Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.

...

But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.

Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.

Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?

SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/22/2013 02:43 PM, Ruediger Meier wrote:

[...] You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.

I do understand that concern but opening *all* bugreports is not practical. Yes, we can and should open more bugreports... Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:

On Friday 22 November 2013, Andreas Jaeger wrote:

...

On 11/22/2013 03:00 PM, Ruediger Meier wrote:

...

On Thursday 21 November 2013, Adrian Schröter wrote:

...

Am Donnerstag, 21. November 2013, 14:16:48 schrieb Claudio Freire:

...

On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert wrote:

..

...

...

This would mena that someone has to do this e.g. for all referenced security bugs, all SLES/SLED bugs and much more.

Supposedly, the work for extracting a minimal description of the bug into a public source would be small compared to actually fixing the bug.

True, but this can be done directly in the .changes file. Some description about the change had to be written there anyway.

If that description is not good enough openSUSE-Factory maintainers can of course reject the package.

Well, IMO the maintainer can only objectively rate the description if he also can't access the bnc.

...

But please keep in mind that openSUSE is currently using SUSE bugzilla. I do not think want to double the effort to maintain an own bug system and to sync the data always. So we need some compromise here.

Of course we could also build in some OBS feature to track some data elsewhere and jsut generate it inside when it got built within a different context. But I think it will create too much confusion for most people.

Actually I don't understand the problem completely. Are SLES customers able to access all the bugs?

SLES customers report bugs to NTS which then open bugs - and partners report directly to NTS. Both groups might include private information. Partners for example have only access to the bugs they reported,

So then it's even annoying for SLES customers to see all these private references. Suse should track their private references elsewhere as you mentioned.

You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ... However, I am actually happy that we have only one. In most cases it makes the collaboration much easier. bye adrian -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/22/2013 03:33 PM, Adrian Schröter wrote:

[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...

That's not the problem. The problem is the following workflow: SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number. If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx", Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Andreas Jaeger :

On 11/22/2013 03:33 PM, Adrian Schröter wrote:

If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",

Which is something 'we' devel project maintainers can do (and do!). Most of the time I run into 'closed' issues when it comes to identify if a patch is still valid; a clear 'bug statement and how to reproduce the bug' is often missing (or references to test documents). This is not something I'd expect to be all put into the .changes... but then, honestly, those happened 'once in a while' to me only and either I contacted any of the nice folks I know with a @suse email address and ask them to open it or at least give me a summary and eventual information available to validate it. Certainly not a good workflow, but probably it also puts more load on @suse folks than it puts on me. Dominique PS: At this point, a thanks to all the suse folks that DO help me get to those things in the past! You know who you are... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 22 November 2013, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Andreas Jaeger :

...

On 11/22/2013 03:33 PM, Adrian Schröter wrote:

If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",

Which is something 'we' devel project maintainers can do (and do!).

I guess you only do this because you are one of us without @suse. Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org: ------ openSUSE Security Update: kernel: security and bugfix update ______________________________________________________________________________ Announcement ID: openSUSE-SU-2013:0396-1 Rating: important References: #714906 #720226 #733148 #755546 #762693 #765524 #768506 #769784 #769896 #770695 #773406 #773831 #774285 #774523 #774859 #776144 #778630 #779432 #781134 #783515 #784192 #786013 #787168 #792500 #793671 #797175 #799209 #800280 #801178 #801782 #802153 #802642 #804154 #804652 #804738 Cross-References: CVE-2012-0957 CVE-2012-2745 CVE-2012-3412 CVE-2012-4530 CVE-2013-0160 CVE-2013-0216 CVE-2013-0231 CVE-2013-0268 CVE-2013-0309 CVE-2013-0871 Affected Products: openSUSE 12.1 [...] ------ Such emails should be rejected automatically. The plans in Tomáš initial email are a nice first step. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 22 November 2013, Adrian Schröter wrote:

Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:

...

On Friday 22 November 2013, Adrian Schröter wrote:

...

Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger Meier:

...

No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.

Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.

Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links. Imagine a wikipedia where companies would add nice informations but references are private links to private sites. This is only no problem if you belong to that company. BTW how other companies are doing this? Does Oracle also post cryptic/private references on their published Java release notes? I don't think so. But I'm sure that they also track additional private stuff somewhere else. It is possible and should be done that way.

Could we agree that we may need to mark them differently, eg. with a different tag so no one is loosing time trying to open it?

This would be better already but maybe a bit annoying if somebody makes such bugs public later.

...

...

However, I am actually happy that we have only one. In most cases it makes the collaboration much easier.

One thing would be nice. I'd like to have a blacklist in my bugzilla preferences for all the "uninteresing" Classification, Product, Component drop down lists. Maybe this would be a new bugzilla feature ?!

well, I dunno in which situation this shall happen. Just because your account is marked that you are an openSUSE use does not say you have not any other product.

Usually a good idea is store specific searches. That is at least what I do when jumping between my different roles.

Yep, I should do this. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Friday 22 November 2013, Andreas Jaeger wrote:

On 11/22/2013 04:57 PM, Ruediger Meier wrote:

...

On Friday 22 November 2013, Adrian Schröter wrote:

...

...

Am Freitag, 22. November 2013, 15:44:59 schrieb Ruediger Meier:

...

...

On Friday 22 November 2013, Adrian Schröter wrote: > > Am Freitag, 22. November 2013, 15:14:50 schrieb Ruediger > > Meier:

No, I don't care about about private bugs in bugzilla. I just don't want to have them in submit messages, changelogs and patchinfo of openSUSE packages.

Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.

Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.

They help you indirectly.

Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.

Without the bnc numbers it would be really hard to figure out...

I know this because I cannot figure out already now ... cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Nov 22, 2013 at 1:17 PM, Ruediger Meier wrote:

...

...

...

...

...

> No, I don't care about about private bugs in bugzilla. I just > don't want to have them in submit messages, changelogs and > patchinfo of openSUSE packages.

Again, just removing information does not help anyone and will have bad impact on the workforce in openSUSE Factory.

Hm, seems you cannot understand this because you _have_ access. From my point of view we wouldn't remove any information if we remove those dead links.

They help you indirectly.

Having them in allows to review whether all patches that were done for SLES are also done for openSUSE. We had a couple of engineers looking especially at this during the last year so that openSUSE does not miss anything important.

Without the bnc numbers it would be really hard to figure out...

I know this because I cannot figure out already now ...

You can. You don't know what the patch is about, but you know patch 3824783 is in both at least. I think an enhancement to the WebUI or OSC that warns about private bnc references on checkin would be best. Something like source validation, but that emits a warning and lets the commit in. Because I'd bet many of those bugs remain private because SUSE employees don't even notice they're introducing dead links for the rest. If they knew, they'd be able to take care of it. The review interface could also mark it, and that would help package reviewers. If you see a private bnc reference, you'll know to check extra carefully whether the changelog text is self-sufficient. If not, you can relax. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Nov 22, 2013 at 1:30 PM, Robert Schweikert wrote:

On 11/22/2013 10:07 AM, Dominique Leuenberger a.k.a. Dimstar wrote:

...

Quoting Andreas Jaeger :

...

On 11/22/2013 03:33 PM, Adrian Schröter wrote:

If we really want the SUSE developers to fix the bugs, we have to live with some private bugs. Yes, we should ask for clear descriptions and not just "fix bnc#xxxx",

Which is something 'we' devel project maintainers can do (and do!).

Most of the time I run into 'closed' issues when it comes to identify if a patch is still valid; a clear 'bug statement and how to reproduce the bug' is often missing (or references to test documents).

This is not something I'd expect to be all put into the .changes...

This should be addressed by "No private initial description allowed". We expect information about the bug and reproduction steps in the initial description. None of that should be "private" sensitive data.

You never know. If the bug is about privilege escalation and there's steps to reproduce THAT... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 21, 2013 at 11:32:54AM -0500, Robert Schweikert wrote:

However, I believe there is a way forward, and here is my proposal:

1.) Modify bugzilla such that the initial description cannot be marked as "Private". + This ensures, so one would hope, no sensitive data will be posted to the initial description + This also ensures that going forward bugs are public

Consider L3 bugs which are private by policy. They are opened by NTS guys who sometimes have no idea about the problem in which case they copy and paste the e-mail they get from the customer - which is in such case much better than trying to rephrase the description. If we force the "initial comment must be public" policy by technical means, I'm afraid the result may be that we will have a lot of bugs with either public initial comment containing non-public information (so that we can never make the bug public) or just a formal initial comment not describing the problem at all (and the real description in Comment 1). Another problem are TP-L3 bugs which are opened by people from other companies who now expect their comments to be seen only by us and by them. If your proposition was accepted, we would have to explain to all of them that their initial description would become public one day and that they have to keep that in mind. And hope that all of them will. I don't believe this is going to work. Yes, I admit that facing the idea of having to go through all the comments (sometimes even few hundred of them) and attachments every time I close a bug and to fix their visibility is not very appealing to me. But I will cope with it if I have to. However, the problem with enforced public initial comment potentially containing non-public information is something we must take into account. And we should also keep in mind that it's actually neither OpenSuSE bugzilla nor SuSE bugzilla. It's Novell bugzilla we just share with them. So either the feature would have to be limited to (Open)SuSE products (which is not easy because sometimes it's not clear from the start whom does the bug belong to) or Novell would have to agree with it. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 22.11.2013 15:06, schrieb Johannes Meixner:

Hello,

On Nov 22 08:40 Stephan Kulow wrote (excerpt):

...

I think a better approach is if bernhard's SR->bugzilla interface mails the submitter if the bug is not public and then let the submitter decide if it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.

I do not fully understand who "the submitter" is.

If "the submitter" is the one who submitted the fixed package then usually "the submitter" is not the one who can decide if the bug should be made public.

Assume the legal-team had filed a closed bug and assigned it to "the submitter" who then submitted a fixed package, then "the submitter" cannot make the bug public.

How could "the submitter" find out who the right one is who can actually decide and actually make a bug public?

But if you submit a package with a bug fix mentioned, you can actually go into the bug and ask legal-team if they are fine with opening the bug if it appears to be community relevant. Noone else can Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Nov 22, Ruediger Meier wrote:

Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:

------ openSUSE Security Update: kernel: security and bugfix update ______________________________________________________________________________

Announcement ID: openSUSE-SU-2013:0396-1 Rating: important References: #714906 #720226 #733148 #755546 #762693 #765524 #768506 #769784 #769896 #770695 #773406 #773831 #774285 #774523 #774859 #776144 #778630 #779432 #781134 #783515 #784192 #786013 #787168 #792500 #793671 #797175 #799209 #800280 #801178 #801782 #802153 #802642 #804154 #804652 #804738 Cross-References: CVE-2012-0957 CVE-2012-2745 CVE-2012-3412 CVE-2012-4530 CVE-2013-0160 CVE-2013-0216 CVE-2013-0231 CVE-2013-0268 CVE-2013-0309 CVE-2013-0871 Affected Products: openSUSE 12.1 [...] ------

Such emails should be rejected automatically. The plans in Tomáš initial email are a nice first step.

And the people who can read that bugs would complain, because they don't know if their bug is fixed with this release or not. Please start thinking about the consequences not only for you personal, but for other people, too. And no, I don't speak here about SUSE employees. Only because you cannot see a bug, this does not mean other external cannot see it, too. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Nov 22, 13 14:43:20 +0100, Ruediger Meier wrote:

On Friday 22 November 2013, Stefan Behlert wrote:

...

Moin,

On Nov 21, 13 14:16:48 -0200, Claudio Freire wrote:

...

On Thu, Nov 21, 2013 at 1:04 PM, Stefan Behlert [...]

I think if the short description in the changelog is "obscure", it's not because of the bugnumber ;) Realistically, if the changelog is good, how many people check all the bugnumbers?

Packagers are doing it. If you read patch-xyz has been added because of bnc1234 then 1234 must be public.

Good point. But I am still thinking that a good changelog helps here more than a bugreport that may have information that is not even understandable (I have seen everything, from spanish to german to something that seemed to be english :) ).

...

(Note: In an enterprise world the number here is 100% or close to, but I have my doubts that in openSUSE this is identical. But I have no numbers, so feel free to correct me.)

...

So, what do you propose? What *can* SUSE employees do to improve that situation?

My suggestion is to NOT change the current behavior, but put more emphasis on good changelog texts.

You should log out from bugzilla for one week to get the feeling of us 2nd class packagers. It's not much fun with all these random non-sense bug numbers.

Oh, I know how this feeling is. I am also not allowed to see all bugs, as I am not part of the Security-team. As said, I inderstand your concern and wishes, I jsut do not think they are practical. But despite pushing internal to get people less restrict (some bugs really could be opened instead of hidden under the table), I see no solution, sorry. Stefan [...] -- Stefan Behlert, SUSE LINUX Project Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/25/2013 03:16 AM, Stefan Behlert wrote:

On Nov 22, 13 11:28:02 -0500, Robert Schweikert wrote:

...

On 11/22/2013 10:00 AM, Andreas Jaeger wrote:

...

On 11/22/2013 03:33 PM, Adrian Schröter wrote:

...

[...] You forget that openSUSE is using SUSE bugzilla. So openSUSE would need to look for a new bug tracker ...

That's not the problem. The problem is the following workflow:

SUSE developer gets a (private) bugreport and fixed it in package Y for SLES 11. Then s/he fixes the same bug for openSUSE factory and references the private bugzilla number.

But why does the initial description have to be private. See my proposal earlier in the thread.

My fear is, that this would result in some cases in bug descriptions like "see coment 1. closed description due to security/private issues".

Yes, we would get some cases like this. However we would also get plenty of cases where the initial description is public and useful enough to understand the problem even if most or all remaining comments in a bug might be marked as private. We have to get over the "all or nothing" mentality and we should not let corner cases prevent a solution that might generally present positive change. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Tomáš Chvátal wrote:

Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2]

Since I was the one asking for that feature but unfortunately was on vacation when the first implementation was proposed. So let me respond to a few concerns brought up in this thread. - There is no security background on this request. It's just for the sake of allowing people to check the reason of changes, allow them to comment on them in the right place and potentially also allow them to re-open the bug if needed. It's a PITA having to ask people via side channels to open bug reports and then wait days to get a reaction. Anyone who was in the situation of having to deal with e.g. Legal bugs assigned to others knows how it interrupts your workflow and how bad it feels. - Legal bugs not being public is for legacy reasons and the way bugzilla is currently set up. I've been talking to people about getting openSUSE legal bugs public by default. There seems to be an agreement and a way to achieve that. Implementation pending. - It is true that the initial description of bugs cannot be modified. So if you accidentally pasted stuff there that shouldn't be public you have to mark it private and provide a better summary in another comment as workaround. That is a limitation of our bugzilla instance and could be fixed. - Security bugs are not public only when there is an embargo. During that period there are no requests that concern factory-auto. When a security issue becomes public the SUSE Security Team makes the bug public. The security team files bugs already having in mind that the bug will have to be made public at some point exactly because of the aforementioned limitation. Any really sensitive information is kept private of course. Bug comments and attachments are reviewed before actually opening up a bug. Err on the safe side. I've been doing that myself for years, it's not a big deal and worth the extra effort to make the work more transparent. - If it's technically not possible to make SLE bugs public because the check box is missing then this this can be fixed by changing the product configuration in bugzilla. Wrt sensitive information in there the same process as security follows for years already can be applied. It's just a matter of willingness to do that. - Wrt the implementation I agree that the checker should only look at the diff and not require changing legacy bugs. - A rejection by factory-auto is not an ultimate failure. If the submission got rejected because of a non-public bug you are free to re-open the request. If the reviewers are fine that, fine. Still maybe that little extra step helps to raise awareness and reduce the number of actually needlessly private bug reports. - obviously other distros aren't perfect either. That doesn't mean we should use that as excuse for not improving ourselves. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia czwartek, 21 listopada 2013 16:12:35 Dominique Leuenberger a.k.a. Dimstar pisze:

So as a consequence I can no longer submit a security fix to address a 'non-public vulnurability' before opening the bug and making it public? :)

Submitting a security fix makes the bug public anyway because the fix tells you where the bug is. This is even true for closed-source binaries. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia piątek, 22 listopada 2013 23:05:21 Thorsten Kukuk pisze:

On Fri, Nov 22, Ruediger Meier wrote:

...

Just an example what we are talking about. For example emails like this from opensuse-updates@opensuse.org:

And the people who can read that bugs would complain, because they don't know if their bug is fixed with this release or not.

They are reading the wrong list then. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 28.11.2013 00:13, schrieb Křištof Želechovski:

Dnia piątek, 22 listopada 2013 08:40:45 Stephan Kulow pisze:

...

it should be opened up, because a lot of bugs *do* make sense to be open and are just not open because e.g. legal-team always opens up closed bugs even if the problem is just a missing COPYING in a GPL package.

What do you mean by that? If the legal team opens a closed bug, it is open, isn’t it?

Words... :) legal-team always _creates_ _private_ bugs. Does this make more sense to you? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier (sweet_f_a@gmx.de) wrote:

BTW it would be really nice if OBS packages would be git repos. Packages in different projects would be just different branches of one "imaginary common repo". This would make life a lot easier and you could add the unique revision numbers to the bug reports to check even automatically whether a fix is already _merged_ or not. Having a mapping into both directions between bugs and fixes (git revs) would make it possible (for everybody) to track all kind of additional private infos wherever.

Yes, that would be really great. A while ago I tried to revive Andreas Grünbacher's bsgit work: https://files.opensuse.org/opensuse/old-en/5/55/Git-in-the-build-service.pdf but I only got as far as building the packages: http://software.opensuse.org/package/bsgit and didn't actually see what it does yet. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org