On 29/05/18 00:49, Anton Aylward wrote:

On 28/05/18 10:46 AM, Simon Lees wrote:

...

In order to make this process slightly easier and more formal during las weeks board discussion the board decided to the mailing list opensuse-bugshare@opensuse.org where community members can send an email then a volunteer SUSE employee can read the bug report then either open it or provide a summary.

Currently this is a short term solution, SUSE Engineering understands this problem and will be working toward a better solution longer term.

I hope this is a short term and I'm not happy with it. I'm already subscribed to about half a dozen <something>-opensuse.o.o lists. many of them are very low volume. In a different world I could see them not be separate from a more general single list and then filter/flag/sort them in my reader. Readers are very capable these days.

So far, Simon, your reported proposals have been about increasing the proliferation of lists we need to subscribe to and reducing the focus. I can see how it makes life easier for (some) developers, but I don't think it makes life simpler or easier for those of us who have to run and/or maintain systems for our employers and clients.

As I said, elsewhere, not all problems are bugs. Those that are not are better solved by the Wisdom of Crowds than annoying a single developer who has limited time and patience.

Apart from that, there is an inherent assumption that I'm not sure is valid enough to make this workable. It is that a SUSE employees will take time out from addressing the needs of the paying clients, the ones that are paying his salary, to address the needs of a 'maverick' outsider who isn't. I'm sure that there are kind and generous souls who will do this, but memories of first line support for a UNIX shops was that it was a 'rite of passage' that new hires went though and that management demanded the developers do once in a while to remind them that "It was the paying customers who matter". They resented that. back when I SysAdmin'd a AIX shop and was submitting at least 4 bug reports a day, REAL bug reports that had the developers in Texas mad at me, the local manager assigned a new hire to field my reports. "She'll learn more in month dealing with your reports than most of us learn in a year". AIX has got a lot better since those early days :-)

But not all problems are bugs. Deep debugging can be challenging and infuriating, but the resolution gives satisfaction. Dealing with users making their own <strike>idiocies</strike> mistakes into bug reports is frustrating and annoying.

I hope this *IS* a short term solution since in the longer term the Suse developers will get annoyed enough to stop volunteering <strike>to deal with idiots</strike>.

You completely missunderstand this whole thread, no one needs to subscribe to another mailing list here (we expect you not to be subscribed to use this list). The only people subscribed to this list are SUSE employees willing to work through the bugs. Also give us a little credit, before creating the list we attempted to make sure we have enough employee's volunteering to make this work, currently Richard and myself have both volunteered as have two other people, if demand for this gets so great that we can't manage then we will atleast have a much greater idea of the need and the board will be able to take that to SUSE Management and ask them for further assistance. The whole idea started because some of us have been asked about bugs or seen questions raised about them on obs / irc / mailing lists and have then gone and got the information or made the bug public this process is just slightly formalising something that is already happening within the community. -- 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 2018-05-28 18:39, John Paul Adrian Glaubitz wrote:

On 05/28/2018 05:19 PM, Anton Aylward wrote:

...

As I said, elsewhere, not all problems are bugs. Those that are not are better solved by the Wisdom of Crowds than annoying a single developer who has limited time and patience.

I agree with that. I have made the experience from Debian that many users abuse the bug tracking system as a support forum. It can be quite frustrating when you are overrun with invalid bug reports which were just reported because users are unable to tell a bug from a local configuration issue.

...

But not all problems are bugs. Deep debugging can be challenging and infuriating, but the resolution gives satisfaction. Dealing with users making their own <strike>idiocies</strike> mistakes into bug reports is frustrating and annoying.

I hope this *IS* a short term solution since in the longer term the Suse developers will get annoyed enough to stop volunteering <strike>to deal with idiots</strike>.

Yes. If you tell people to report a bug every time they run into a problem, you will have your bug tracker flooded with invalid bug reports.

I agree. But perhaps we are mixing here ideas from two different threads and there is some confusion. This mail list proposed in this thread, opensuse-bugshare@opensuse.org, is only to handle requests by people to make public a particular bug report they need to read, but can not because it is flagged "private" (most SLE bugs are marked private, it is the default as I understand). Then a volunteer employee, who has access to those private bugs because he is an employee, will either make the bug public or post to the list an excerpt or a copy paste of the needed sections. However, this service can be useful not only to people solving bugs, but also to people reading that a solution to bug X is included on some other bug Y that he can not read because it is private. I have hit them more than once, so I expect that I would need this mail list eventually. Thank you for providing this service to the community :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 29/05/18 05:05 AM, Simon Lees wrote:

If as in the case suggested in this email you have tried to setup a webserver for example and something is not working and your not sure if you did it wrong or you found a bug, you should not file a bug you should ask for help on opensuse-support@

I think you are assuming a high degree of stupidity or naivety on the part of the person setting up the web server. As it "It doesn't work" and (s)he stops there. I suppose there are people that dumb, but I'd expect them to use the "Free and easy web site creation tool" at their ISP. It probably comes advertised, thank you web-safe colouring, in a presentation that is brighter than then packaging for Barbie dolls. I'd expect a user with the sophistication to sign up for this list to be a bit more capable than that, tried to read up on it, had the web server as step to running a specific web service/application. So there's the issue of the database, the application language and the database. The installation guide for the application, and its the application that counts as far as (s)he's concerned, mentioned these things and now (s)he's wondering which one is the problem. So long as there are the lists at https://lists.opensuse.org/ then (s)he's going to have a choice: be generic, as in opensuse@ "Generic questions and User to User support for all the openSUSE distributions" or a specific like database-, or security-; depending on what his(her) problem was. Or ask why there isn't a perl- or a PHP- list? But yes, you mentioned getting rid of all the lists. So we'll be left with just opensuse-support@ and perhaps a feed. And many of us don't like the feed. Much too noisy. Many other shortcomings. Really too much in a limited view of the present. Perhaps that means many people will move to Fedora, where there are still a lot of lists, much more specific and much more fine grained (and apparently more populous). Saying "go to opensuse-support@ for all matters" is as unhelpful a saying "go to bugzilla ..." for support. -- When we try to pick out anything by itself, we find it is tied to everything else in the universe. -- John Muir (1838-1914) U. S. naturalist, explorer. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30/05/18 00:17, Simon Lees wrote:

On 29/05/18 23:25, Anton Aylward wrote:

...

On 29/05/18 05:05 AM, Simon Lees wrote:

<pruned>

As far as I recall this is the first email where I have discussed getting rid of any lists, I can't see the board deciding to remove any lists that still have a function and that are still being actively used. Personally I would not support such a change. The bulk of the change we have announced and implemented is about A. Providing a more focused support list and B. returning the opensuse-factory@ list back to its role from 2-5 years ago, discussing development changes / decisions that effect distro development as a whole,

The name of that list (Factory) is inappropriate for what it is supposed to cover and should be renamed to, I suggest, 'Development'.

see the "remove groups from .spec files" thread that is currently running as an example of this kind of discussion.

...

So we'll be left with just opensuse-support@ and perhaps a feed. And many of us don't like the feed. Much too noisy. Many other shortcomings. Really too much in a limited view of the present. Perhaps that means many people will move to Fedora, where there are still a lot of lists, much more specific and much more fine grained (and apparently more populous).

Saying "go to opensuse-support@ for all matters" is as unhelpful a saying "go to bugzilla ..." for support.

You know, I think that "we" are looking at this matter from 'inside the box' and should look at it from 'outside the sandbox'. Someone for some reason many moons ago created a list called Factory. Now, at that time the name was appropriate for whatever reason but now a newbie would see that list name and wonder what the heck is that all about. The reason why I suggested above for the name to be changed to Development (or something along this line). The same applies to the name if this new mail list, opensuse-support. The name is too broad, too meangingless. Why not call a spade a spade and make the name 'Leap/Tumbleweed Users' Support' or similar. Direct, to the point. A newbie sees this name and knows exactly what to expect when s/he subscribes to the list. The name is too long, you say? OK, make it 'Leap/TW Support'. BC -- "..The times have been That, when the brains were out, the man would die,.." "Macbeth", Shakespeare -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

(snip a bit)

Our aim with this change is primarily to make it easier for community contributors to work alongside SUSE employee's and as I said this is just a starting point in making life easier rather then the final solution.

Thanks Simon for the explanation, I'm looking forward to see this first step appearing soon. It is at least better that the last 3 years glue ;-) BTW thanks for those on the other side, that will render this possible. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28/05/18 12:12 PM, Simon Lees wrote:

...

As I said in my original email SUSE Engineering is currently looking into how they can do this but at the same time stay within there various requirements that ensure customer information stays private.

I can read that as "they can benefit from our experience and bug reports because we're not 'professional' enough but we can't benefit from theirs".

Please explain why this is not the case. Come on, that's simply not how it works. Reread Simon's first post. It's an

Op maandag 28 mei 2018 19:29:04 CEST schreef Anton Aylward: option to provide openSUSE packagers/devs info on bugs that ( for customer data's sake ) are private in SUSE's bugzilla. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29/05/18 02:59, Anton Aylward wrote:

On 28/05/18 12:12 PM, Simon Lees wrote:

...

As I said in my original email SUSE Engineering is currently looking into how they can do this but at the same time stay within there various requirements that ensure customer information stays private.

I can read that as "they can benefit from our experience and bug reports because we're not 'professional' enough but we can't benefit from theirs".

Please explain why this is not the case.

There are various certifications that SUSE needs to have in order to fulfill many of there contracts with customers, these state alongside other things that customer info must remain private. In the past before the shared code base the easiest most logical way to do this was to simply make all SLE bugs private, as I said SUSE Engineering understands this won't work into the future and are looking into alternatives. -- 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 29/05/18 23:43, Anton Aylward wrote:

On 29/05/18 04:05 AM, Simon Lees wrote:

...

...

...

tomer information stays private. I can read that as "they can benefit from our experience and bug reports because we're not 'professional' enough but we can't benefit from theirs".

Please explain why this is not the case.

There are various certifications that SUSE needs to have in order to fulfill many of there contracts with customers, these state alongside other things that customer info must remain private. In the past before the shared code base the easiest most logical way to do this was to simply make all SLE bugs private, as I said SUSE Engineering understands this won't work into the future and are looking into alternatives.

I can see that there is customer info that must remain private. I, too, an a 'customer' for various entities and I have to supply them with with information such as credit card numbers.

But let's face reality. Even without the 'Net there's a vast amount of information about me available. My birth certificate is on record and that record is publicly available in the appropriate government building. A vendor or bank for financial organization can access my credit history. My address, residency and residency rail are available as public records such as voter registration. If you go and read some detective novels they mention quite a few pre-Internet techniques of finding 'personal information".

Corporate entities are just as easy. SUSE promotional material mentions quite a few of its customers. Their HQ addresses are easy to look up, even off-line. Shareholder reports list directors and the management team, and they can be looked up as well. Those same shareholder reports give a lot of other information about various offices and so forth. Then there's the filings with SEC and in some cases publicly available information that they needed to supply to governments and QUANGOs for a whole host of reasons.

But yes, like me and my credit card numbers there is a core that is private.

But I don't see how a bug in FOSS software is in that category. I don't see that the fact that Company X uses a specific application made of FOSS software is "private customer information".

Perhaps it would help clear up this matter if you could tell us what class of information is so sacrosanct, what information I couldn't search & find or derive using conventional "detective" methods that I read about in detective or detective-lawyer novels.

If you read this thread carefully you will find people giving many examples for now I will give 1 big obvious one. SUSE has many non disclosure agreements (NDA)'s with its customers. Regularly there is information covered by such agreements in bugzilla. This is just one example others may include logs from customer machines etc. Previously the easiest way for SUSE to handle this was just creating all SLE emails as private, as I have said SLE Engineering understands that doing things this way causes issues and are looking at ways to change the way they do things, but we as the openSUSE board believe this will be a medium to long term change so in the mean time we created the mailing list to make the lives of community members working on openSUSE easier. -- 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 30/05/18 02:18, Stefan Seyfried wrote:
> Am 29.05.2018 um 16:13 schrieb Anton Aylward:
>> On 29/05/18 04:05 AM, Simon Lees wrote:
>> I can see that there is customer info that must remain private.
>> I, too, an a 'customer' for various entities and I have to supply them with with
>> information such as credit card numbers.
>>
>> But let's face reality.
>> [snip]
>> But I don't see how a bug in FOSS software is in that category.
>> I don't see that the fact that Company X uses a specific application made of
>> FOSS software is "private customer information".
> This information is really mostly harmless.
> But when I report a bug at work, I add
> * log files (host names, IP addresses)
> * config files (host names, IP addresses, config options, security
> settings, ...)
> * a detailed description of our specific setup (in the "how to
> reproduce" section)
> * a detailed description of the system tuning, make and model of the
> used hardware, ...
> * crashdumps (unlikely to end up in bugzilla due to their sheer size,
> but maybe parts of them from the debugger tool output)
>
> This is probably not only data of the company I work for, but also from
> our customers.
>
> This all is clearly confidential, as it would for example be interesting
> for attackers trying to sneak into our network, or for competitors.
>
> Because of this, SUSE had to sign a NDA with us for us to even consider
> buying subscriptions / support, and my employer would surely sue the
> hell out of SUSE, Microfocus, whoever if this would not be respected.
> I think this is the same with most other customers.

And yet you just said that the info. you provide SUSE in a bug report 
may contain customer information... Ouch!


> Perhaps it would help clear up this matter if you could tell us what 
> class of
>> information is so sacrosanct, what information I couldn't search & find or
>> derive using conventional "detective" methods that I read about in detective or
>> detective-lawyer novels.
> HTH

BC

-- 
"..The times have been
That, when the brains were out,
   the man would die,.."
                  "Macbeth", Shakespeare

-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30/05/18 12:58, Carlos E. R. wrote:
> On 2018-05-30 04:24, Basil Chupin wrote:
>> On 30/05/18 02:18, Stefan Seyfried wrote:
>>> Am 29.05.2018 um 16:13 schrieb Anton Aylward:
>>>> On 29/05/18 04:05 AM, Simon Lees wrote:
>>>> I can see that there is customer info that must remain private.
>>>> I, too, an a 'customer' for various entities and I have to supply
>>>> them with with
>>>> information such as credit card numbers.
>>>>
>>>> But let's face reality.
>>>> [snip]
>>>> But I don't see how a bug in FOSS software is in that category.
>>>> I don't see that the fact that Company X uses a specific application
>>>> made of
>>>> FOSS software is "private customer information".
>>> This information is really mostly harmless.
>>> But when I report a bug at work, I add
>>> * log files (host names, IP addresses)
>>> * config files (host names, IP addresses, config options, security
>>> settings, ...)
>>> * a detailed description of our specific setup (in the "how to
>>> reproduce" section)
>>> * a detailed description of the system tuning, make and model of the
>>> used hardware, ...
>>> * crashdumps (unlikely to end up in bugzilla due to their sheer size,
>>> but maybe parts of them from the debugger tool output)
>>>
>>> This is probably not only data of the company I work for, but also from
>>> our customers.
>>>
>>> This all is clearly confidential, as it would for example be interesting
>>> for attackers trying to sneak into our network, or for competitors.
>>>
>>> Because of this, SUSE had to sign a NDA with us for us to even consider
>>> buying subscriptions / support, and my employer would surely sue the
>>> hell out of SUSE, Microfocus, whoever if this would not be respected.
>>> I think this is the same with most other customers.
>> And yet you just said that the info. you provide SUSE in a bug report
>> may contain customer information... Ouch!
> Obviously.
>
> It is very difficult to sanitize a log from all such delicate
> information, and in doing so, you might modify unknowingly information
> that is crucial for diagnosing the bug.
>
> Marking bugs private is a need. For instance, yesterday I submitted an
> entire virtual machine dump in an effort to help reproduce a problem in
> a bugzilla. I do not wish the entire internet to have access to it,
> would you?
>
> Yet, if a solution is found for the bug, it has to be published. But not
> my virtual machine.
>
> Suppose an investigation of a mail problem. You submit the mail logs -
> which has the mail addresses of internal and external contacts, and
> perhaps passwords!  Yes, you can sanitize them, but this is excruciating
> job and the resulting obfuscation might forget things, or impede the bug
> diagnosis.
>
> So SUSE needs the whole logs, and has to keep them secret. I would think
> that perhaps they be erased after the investigation.
>
> It is a difficult problem. SUSE, and sometimes openSUSE, needs to be
> able to mark some information private, simple as that.

Carlos, you are missing the point of my comment.

BC

-- 
"..The times have been
That, when the brains were out,
   the man would die,.."
                  "Macbeth", Shakespeare

-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 30 May 2018 10:11 Sarah Julia Kriesch wrote:

That's a topic for group security in Bugzilla. I know from other issue trackers, that it is possible, that attachments are only readable/ to download from a specific group in the project. So we can create groups like SUSE and openSUSE. We should try that with Bugzilla [1].

We actually already have a group for SUSE employees (and few others) and they are used for access control.

I would be surprised, if it isn't possible to have security rules for attachments. So customer data can be safe.

An attachment can be also flagged as private (like comments), that's not a problem. The problem is that there is no way to make them flagged automatically, so that human review is necessary before opening a bug, for both comments and attachments. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30/05/18 18:59, Sarah Julia Kriesch wrote:

...

Gesendet: Mittwoch, 30. Mai 2018 um 10:49 Uhr Von: "Michal Kubecek" An: opensuse-factory@opensuse.org Cc: "Sarah Julia Kriesch" Betreff: Re: [opensuse-factory] Opening private bugs

On Wednesday, 30 May 2018 10:11 Sarah Julia Kriesch wrote:

...

That's a topic for group security in Bugzilla. I know from other issue trackers, that it is possible, that attachments are only readable/ to download from a specific group in the project. So we can create groups like SUSE and openSUSE. We should try that with Bugzilla [1].

We actually already have a group for SUSE employees (and few others) and they are used for access control.

...

I would be surprised, if it isn't possible to have security rules for attachments. So customer data can be safe.

An attachment can be also flagged as private (like comments), that's not a problem. The problem is that there is no way to make them flagged automatically, so that human review is necessary before opening a bug, for both comments and attachments.

Michal Kubecek Hmmh... The default setting for attachments[2]: is_private = false

We have to figure out, how to change those default settings.

Best regards, Sarah

No we don't need to figure that out this is something for SUSE Engineering to work through, sometimes the Summary and bug description also contain private info that can't be shared. Making changes to whether bugs are public / private by default is something that requires organizational change within SUSE Engineering, we as the board were told at our face to face meeting that SUSE Engineering is already assessing the best options for this as they look at other changes to tooling and that we can expect a change in the medium term but not straight away. The mailing list was created as a temporary work around until better changes happen from SUSE Engineering. How SUSE chooses to report its bugs is not something the openSUSE Community can change, we can only tell them that there is an issue with the current way they are doing things. As it stands they are aware of the issue and are working to do something better but such changes take time. -- 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 Tuesday, 29 May 2018 16:13 Anton Aylward wrote:

Corporate entities are just as easy. SUSE promotional material mentions quite a few of its customers.

Yes, they do. But AFAIK never without their (prior) explicit consent and never in more details than agreed upon. We get many more internal "success story" e-mails telling us about interesting contracts SUSE managed to close - and almost all of them (perhaps even all of them) start with something like "CONFIDENTIAL. FOR INTERNAL USE ONLY." Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30.05.2018 12:46, Carlos E. R. wrote:

On 2018-05-30 07:06, Michal Kubecek wrote:

...

Yes, they do. But AFAIK never without their (prior) explicit consent and never in more details than agreed upon. We get many more internal "success story" e-mails telling us about interesting contracts SUSE managed to close - and almost all of them (perhaps even all of them) start with something like "CONFIDENTIAL. FOR INTERNAL USE ONLY."

Pity. They probably not keep a secret when they use Windows and they succeed, but they do when they use Linux. Curious! >:-)

This is not about "Company FOO uses Linux" or "Company BAR uses Windows". Almost all companies I know use both, so there's no news in such an announcement. It's about specific solutions using $PRODUCT of $COMPANY. And those details are often kept confidential, no matter what the underlying operating system is. -- 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 2018-05-28 19:31, Anton Aylward wrote:

On 28/05/18 12:12 PM, Simon Lees wrote:

...

.... or if a community member would like to make changes to a certain package and are wondering why a change was made in a certain way.

That doesn't sound a like "bug report' to me but the sort of question that might be asked on the factory-, application specific or even main lists.

He refers to reading in the changelist, for instance, that "we changed this because of bug #YYYYY", then finding he can not read #YYYYY because it is private, and thus not knowing what to do with the package on the openSUSE side. Yes, it could be asked on the factory mail list, and in fact it has been done, but with a separate mail list the limited number of volunteers can see the request easily. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 29 May 2018 at 05:43, Basil Chupin wrote:

On 29/05/18 06:40, Carlos E. R. wrote:

...

On 2018-05-28 19:31, Anton Aylward wrote:

...

On 28/05/18 12:12 PM, Simon Lees wrote:

...

.... or if a community member would like to make changes to a certain package and are wondering why a change was made in a certain way.

That doesn't sound a like "bug report' to me but the sort of question that might be asked on the factory-, application specific or even main lists.

He refers to reading in the changelist, for instance, that "we changed this because of bug #YYYYY", then finding he can not read #YYYYY because it is private, and thus not knowing what to do with the package on the openSUSE side.

Yes, it could be asked on the factory mail list, and in fact it has been done, but with a separate mail list the limited number of volunteers can see the request easily.

I have read what Simon said (no pun intended) and what others wrote in this thread.

I am confused.

There is the facility for openSuSE (oS) users to report/submit bugs using Bugzilla (whatever). And from what I have read so far, there are cases where the oS user finds out that the bug has either already been submitted or even possibly solved because it concerned the commercial product SUSE/SLE and, therefore, the oS user is unable to see the discussion which occurred or is occurring re the solution to this bug because of customer confidentiality concerns.

So what is now proposed is that after the oS user has gone to Bugzilla and tried to submit a bug report and came across the confidentiality hurdle s/he now will have to write a bug report in this new proposed mail list, opensuse-bugshare@opensuse.org, at which time some SUSE employee with the appropriate security clearance will read the post, analyse it, look for a similar report in the Bugzilla where it is flagged as confidential, read thru that Bugzilla report and try, if it is deemed appropriate, to condense that report into a msg which is to be the response to the oS user who posted his/her bug report in this new mail list.

I have a feeling that I may have misrepresented the actual process of what is being proposed with this new mail list, but the only information I have is what I read so far in this thread.

Now, another aspect of this is that the Linux distro we are using is supposed to be FOSS but this new mail list is based on the confidentiality of customer/SUSE/SLE relationship so the element of "proprietary" is introduced; however, once the bug has been resolved the "fix" is, I am assuming, released for the whole world to see and to apply because SUSE/SLE is FOSS.

The "spanner in the works", if I may call it that, is the confidentiality aspect of bugs concerning SUSE/SLE and because of this it is deemed necessary to have this new mail list.

So why not fix the problem at its 'core'? Why do the bugs reported reported re SUSE/SLE have to be "confidential"? Of course I have no idea what such reports contain but if they contain identifying info. about the organisation which submitted the bug then why not encode the name, for example. If one looks at the mail list archives, the e-mail addresses of posters is replaced with 'XXXXX' so why not do same/similar with bug reports re SUSE/SLE?

What I am suggesting is to 'nip' the problem at the 'bud' stage by having the "bug fixer" (sorry for this crude wording, no offence meant :-)) who first gets to solve the bug do the sanitising of the report so that even oS users can follow the way the bug was/is being solved rather than have another, additional, SUSE employee possibly have to wade thru screenfulls of words to be able to summarise that original report and then write that summary as a response to the oS user in opensuse-bugshare@opensuse.org.

But wait! This cannot be right because the oS user cannot subscribe to this new list -- s/he can only post there. So, how...?

I think it might help to explain a common difference between most SLE bugs and most openSUSE bugs Most openSUSE bugs are filed by openSUSE users and contributors, and typically contain 2 bits of information - "What happened", and "what was expected to happen". A good bug report will also include logs from the system in question. If we're lucky, an exceptionally good openSUSE bug report might also include some kind of description of the "Impact" the bug has on the user in question ie. "How this makes my life harder" The user/contributor is therefore in control and wholly responsible for the public release of any and all information provided. A SLE bug is typically filed by a member of SUSE's support organisation, not filed by SUSE's customers. It will almost always include logs sent to SUSE in confidence. SUSE always recommend that the customer sanitise any logs before sending them but there is always the chance for personal or security sensitive information to be lurking in there. A SLE bug report going through SUSE's support organisation _WILL_ always include a details of the customer, and an assessment of the impact the bug is having on the customer. This may even go so far to attempt to quantify the financial impact the bug could be having on the customer. This is all very important to help SUSE prioritise and professionally address such bugs, but also not the sort of information that SUSE have any right what so ever in releasing to the public. There are also the cases where SUSE partners are often working on new features and functionality under a non-disclosure agreement before the source is made available. Bugs related to such partnering are obviously also not suitable for public consumption, and may even be more heavily restricted within SUSE. And then there are security incidents under embargo, which obviously are private and have to remain so until the embargo is lifted. These are so private that most SUSE employees can't even see them. There are cases where this is not the case - During SLE 15 development, before SLE 15 release, there are obviously less customer bugs (but more of the partner examples). There is even one (VERY EMBARRASSING) example where yours truly reported a bug against SLE, therefore it was private, but as the bug was further investigated the solution and the largest impact was seen in Tumbleweed first. This led to someone emailing me asking for info about what I was changing (because I didn't exactly write the most descriptive changelog entry to one of my submissions), and it really brought home to me the negative side effects of the status quo. In that case I copied the bug to Tumbleweed and although that might be argued to be somewhat redundant (as the bug was already fixed and it was in essence a DUPLICATE from day 1), it does mean the information as to why I changed what I did is now clearly available. SUSE is committed to helping find a solution to these problems, but given the highly sensitive nature of the data involved, this isn't something anyone can expect SUSE to change overnight. SUSE will not play fast and loose with sensitive customer and partner data. I think this is to be respected and praised, even though it is obviously a problem for collaboration with openSUSE. But, SUSE employees who also contribute to openSUSE have been told we can selectively open and/or share details of private SLE bugs as long as we take great care to ensure the sensitive data like described above is not made public. By having this new "send-only" mailinglist, monitored by SUSE-employeed volunteers, we now have one, easy to remember, place for openSUSE contributors to go when they are impacted by the lack of information about a bug. It is not a mailinglist for discussion, just a simple way of reaching out for help to a whole team at once. This should be far more efficient than the previous approach of "just find the nearest SUSE-employeed volunteer and ask them nicely". It also means we should be able to start drawing a more comprehensive picture of just how much of a problem these SLE private bugs are for openSUSE really. Maybe we will find common trends of the sort of bugs who's private state really get in openSUSE's way, and maybe that will help find an easier solution. This is only meant to be a stop gap - a short term solution to help make it easier for the community immediately and help us figure out the best long term solution going forward -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29 May 2018 at 08:36, Michal Kubecek wrote:

It's not only logs, these bugs often contain data files needed to reproduce the issue or packet captures; those would be really hard to sanitize. Not to mention that any sanitization (or rather obfuscation) may hide important information. Any comment can casually mention something about network topology, equipment used etc. Actually, even company name can be a problem - and it's really hard to keep using "customer" everywhere rather than simply the name.

Yup, true

...

And then there are security incidents under embargo, which obviously are private and have to remain so until the embargo is lifted. These are so private that most SUSE employees can't even see them.

Embargoed security bugs are actually not that much of a problem. As security bugs are public by default, even embargoed ones are bound to become public eventually so that involved people (should) keep that in mind from the start and (should) think about which comment or attachment should be private and which not.

Well yes, not a problem from your perspective, but from a non-suse contributors perspective there is no way of knowing that a private bug is private because its a security bug or a normal product bug I expect a fair bit of the bugshares team responses to be "its a security bug, please be patient, it will be public when it can be"

"Normal" bugs, e.g. those coming from L3 process, are worse in this regard. People know these are not public by definition and often don't care to distinguish which comments are strictly internal and which not. Worse, they often mix internal process information with technical discussion in the same comment. It is hard enough to review 100 comments when we want to add customer/partner developers to Cc at some point; reviewing them to allow making the bug public can be a nightmare.

Absolutely, and thanks for bringing that up. it does a good job of highlighting just how tricky the work is the bugshare team have volunteered for Regards, -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 29 May 2018 10:39 Richard Brown wrote:

On 29 May 2018 at 08:36, Michal Kubecek wrote:

...

Embargoed security bugs are actually not that much of a problem. As security bugs are public by default, even embargoed ones are bound to become public eventually so that involved people (should) keep that in mind from the start and (should) think about which comment or attachment should be private and which not.

Well yes, not a problem from your perspective, but from a non-suse contributors perspective there is no way of knowing that a private bug is private because its a security bug or a normal product bug

Security bugs are public by default. The only exception should be embargoed ones but those are only private until the embargo is lifted - and before that they shouldn't be referenced anywhere in public (not even in OBS). In theory, it might be possible to have updated packages released before security team clears the flag in bugzilla but it's very unlikely. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2018-05-29 07:34, Richard Brown wrote:

By having this new "send-only" mailinglist, monitored by SUSE-employeed volunteers, we now have one, easy to remember, place for openSUSE contributors to go when they are impacted by the lack of information about a bug. It is not a mailinglist for discussion, just a simple way of reaching out for help to a whole team at once. This should be far more efficient than the previous approach of "just find the nearest SUSE-employeed volunteer and ask them nicely".

Question. If it is "send-only", the sender will not see the reply unless you send the reply both to mail list and direct to poster. Or perhaps only to the poster. Suppose the same question is asked by another person sometime later (months?). As he can not read the list, he doesn't know that there is a previous answer. Maybe it is not even archived, so perhaps you have to write again another answer. Question 2 / idea. When someone says in a bugzilla that this bug is duplicate of another private bug, instead of then asking on the mail list, the data could simply be posted to the 2nd bugzilla, where is archived and searchable. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-05-29 12:58, Simon Lees wrote:

On 29/05/18 20:13, Carlos E. R. wrote:

...

On 2018-05-29 07:34, Richard Brown wrote:

...

By having this new "send-only" mailinglist, monitored by SUSE-employeed volunteers, we now have one, easy to remember, place for openSUSE contributors to go when they are impacted by the lack of information about a bug. It is not a mailinglist for discussion, just a simple way of reaching out for help to a whole team at once. This should be far more efficient than the previous approach of "just find the nearest SUSE-employeed volunteer and ask them nicely".

Question.

If it is "send-only", the sender will not see the reply unless you send the reply both to mail list and direct to poster. Or perhaps only to the poster.

Yes this is true, but we can manage that

...

Suppose the same question is asked by another person sometime later (months?). As he can not read the list, he doesn't know that there is a previous answer. Maybe it is not even archived, so perhaps you have to write again another answer.

Hopefully in most cases this won't happen as for most bugs we should be able to at least make some parts of the bug public, when / if it does it won't be hard to copy/paste the previous answer

But you see, the information you write in a single post to the person that asked is not public. It is private. Only one person sees it.

...

Question 2 / idea.

When someone says in a bugzilla that this bug is duplicate of another private bug, instead of then asking on the mail list, the data could simply be posted to the 2nd bugzilla, where is archived and searchable.

Yep that would be upto individual package maintainers / whoever is assigned to the bug, or maybe they will even just open up parts of the private bug, this has also happened in the past.

No, I mean. Why doesn't the volunteer team write the info in the bugzilla instead of using email? Ok, ask for it in the mail list, but write the answer in the bugzilla instead. That way it is public and open for anybody to see. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Basil Chupin wrote:

...

I am confused.

There is the facility for openSuSE (oS) users to report/submit bugs using Bugzilla (whatever). And from what I have read so far, there are cases where the oS user finds out that the bug has either already been submitted or even possibly solved because it concerned the commercial product SUSE/SLE and, therefore, the oS user is unable to see the discussion which occurred or is occurring re the solution to this bug because of customer confidentiality concerns.

Hi Basil,

I believe it typically happens when an openSUSE report is closed as a duplicate of a SUSE report - the latter is often not available to non-staff and non-customers. At this point the bug may not have been resolved yet, but the work will be tracked in the private report.

...

So what is now proposed is that after the oS user has gone to Bugzilla and tried to submit a bug report and came across the confidentiality hurdle s/he now will have to write a bug report in this new proposed mail list, opensuse-bugshare@opensuse.org,

As far as I have understood, the list is meant as an interface - you want access to a private bug report, write to the list and ask. The report could be made public or you could be given the info you need. That's exactly what it's about. It gives the SUSE employee the chance to remove the sensitive information before it goes publc. The board has discussed

Op dinsdag 29 mei 2018 07:35:49 CEST schreef Per Jessen: the issue extensively with people from SUSE, and this seems to cover the issue for the short term. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2018-05-29 at 11:38 -0400, Anton Aylward wrote:

On 29/05/18 01:35 AM, Per Jessen wrote:

...

As far as I have understood, the list is meant as an interface - you want access to a private bug report, write to the list and ask. The report could be made public or you could be given the info you need.

Or not. (See Kafka) Or you might be refused. (See Kafka again) Or, just as with governments, you might get a reply that has everything even slightly relevant redacted. (But this being SUSE you can expect that, unlike the governmental redaction, you won't be able to peer 'under' the PDF overlay layer to see the original.)

There is no guarantee and there is just to much hand-waving going on. An unstated NDA allows the matter of 'security' to be invoked to justify just about anything, just as it can justify crippling US industry by increasing the cost of essential raw material or shafting the bulk (100 -9.9)% of US consumers by taxing imported cars and components in the name of security.

There's places where security is essential, but security isn't just about 'privacy'. It's also about Integrity and Availability. https://security.blogoverflow.com/2012/08/confidentiality-integrity-availabi...

Actually I agree with Donn Parker that Availability without Utility is meaningless and in this case I'd argue that the issue is not about privacy as much as it is about Possession & Control.

You are correct. It's about possession & control. SUSE is put into possession of information that the customers want to control access to, and therefore SUSE respects contractual agreements as well as standard laws with regard maintaining that control on behalf of those parties. Back to the crux of your arguments, what concrete do to you find bad or a step in the wrong direction (vs keeping things as they are) in the proposal presented by Simon? You do realize that this is a proposal to *open* (with best-effort) what is currently closed, right? Doing nothing means things remain closed as before. -Scott

Gesendet: Mittwoch, 13. Juni 2018 um 08:26 Uhr Von: "Oliver Kurz" An: opensuse-factory@opensuse.org Betreff: Re: [opensuse-factory] Opening private bugs

On Wednesday, 13 June 2018 08:20:29 CEST Stefan Seyfried wrote:

...

On 28.05.2018 16:46, Simon Lees wrote:

...

In order to make this process slightly easier and more formal during las weeks board discussion the board decided to the mailing list opensuse-bugshare@opensuse.org where community members can send an email then a volunteer SUSE employee can read the bug report then either open it or provide a summary.

Is there supposed to be any feedback after the complaint is submitted? Or will I have to monitor all bugs I complained about to see if they are eventually opened?

I do not even think it is possible to "make a bug open". At least I can't uncheck the according check box for closed bugs :( The best *I* could do is either copy-paste relevant content to an email or clone the bug to an "open" product, e.g. openSUSE Tumbleweed -- You can "reopen" a bug, if you are not happy with the result like "won't fixed". So you don't have to create a new bug /clone the bug then.

Best regards, Sarah -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Good morning Sarah, [Sorry for OT] On 13.06.2018 08:41, Sarah Julia Kriesch wrote:

You can "reopen" a bug, if you are not happy with the result like "won't fixed". IIRC, you cannot open a CLOSED bug, only a RESOLVED or VERIFIED one.

Adding to the confusion, YOU cannot even CLOSE a bug, you need special permissions for that (again, IIRC) I'm quite sure Stefan Behlert can CLOSE SLES bugs ;-) But a bug gets only closed after everyone is really done with it. Again, IIRC. Have fun, -- 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 13.06.2018 08:26, Oliver Kurz wrote:

I do not even think it is possible to "make a bug open". At least I can't uncheck the according check box for closed bugs :(

Check the SUSE-Internal Bugzilla docs (ten years ago, there were some ;-) A closed bug is closed. It gets closed long after it has been RESOLVED FIXED (or whatever resolved state it got). Then you cannot reopen it. At least that's how I remember it from said docs. What we are discussing here, is changing the product or the access restrictions, to "opening it up to the community", regardless of it's NEW/IN_PROGRESS/NEEDINFO/RESOVED/CLOSED database status.

The best *I* could do is either copy-paste relevant content to an email or clone the bug to an "open" product, e.g. openSUSE Tumbleweed

My question was: do I get an response after sending my mail to opensuse-bugshare or do I have to manually check all the bugs I complained about? If I have to check these manually, I will have to invent something to automate this. If I would need to create something™ to automate bugzilla interaction, this would of course be a welcome opportunity to extend it to automatically check on all mentioned bugs in the patchinfo and automate the opensuse-bugshare mails... :-P (which, until today, were all sent manually) -- 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 13.06.2018 08:48, Carlos E. R. wrote:

You should get an email with the information, in some time.

Please tell me how you obtained this wisdom. Guessing about what would be sensible is something I can do for myself. -- 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 13/06/18 16:38, Carlos E. R. wrote:

On 2018-06-13 08:51, Stefan Seyfried wrote:

...

On 13.06.2018 08:48, Carlos E. R. wrote:

...

You should get an email with the information, in some time.

Please tell me how you obtained this wisdom.

Read the entire thread, it is there.

SL> In order to make this process slightly easier and more formal during las SL> weeks board discussion the board decided to the mailing list SL> opensuse-bugshare@opensuse.org where community members can send an email SL> then a volunteer SUSE employee can read the bug report then either open SL> it or provide a summary.

RB> By having this new "send-only" mailinglist, monitored by RB> SUSE-employeed volunteers, we now have one, easy to remember, place RB> for openSUSE contributors to go when they are impacted by the lack of RB> information about a bug. RB> It is not a mailinglist for discussion, just a simple way of reaching RB> out for help to a whole team at once. RB> This should be far more efficient than the previous approach of "just RB> find the nearest SUSE-employeed volunteer and ask them nicely".

And more posts from Richard Brown and Simon Lees in this thread but not all on the same mail list.

Yep this about sums it up, thanks Carlos :-), so far there has only been one example (that didn't actually make it to the list because the list settings were wrong), that particular bug was hard to open because it was reported by a customer but I was able to point the user to the upstream commit that fixed the issue which gave them all the info they needed. -- 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 14/06/18 15:42, Stefan Seyfried wrote:

On 14.06.2018 02:34, Simon Lees wrote:

...

Yep this about sums it up, thanks Carlos :-)

But, as so often with Carlos' answers, it is not related to the question.

...

, so far there has only been one example (that didn't actually make it to the list because the list settings were wrong), that particular bug was hard to open because it was reported by a customer but I was able to point the user to the upstream commit that fixed the issue which gave them all the info they needed.

I have sent 15 mails to opensuse-bugshare, requesting 14 bugs to be opened (one duplicate).

Does this mean, none of my 15 mails reached the list?

AND THAT WAS EXACTLY MY QUESTION (YELLING, SO THAT EVEN CARLOS CAN READ IT!):

Will I get any reply after submitting a mail to opensuse-bugshare@?

I can't remember if the mail system gives an automated reply or not in this case Per CC'd may know. What I can say is that as a subscriber to that list I haven't received any emails from you and generally the mailing list software will tell you if it was unable to forward your email to the list, so the fact I have not received the emails and you have not received a failure to send notice means something strange is up. How long ago did you send the emails? If you had mentioned you had sent emails and were wondering if they had been received in your initial mail this probably would have saved a bit of time, for example it seemed to me that Carlos answered your question in the best possible way from the info I had at the time. I also sent an email from a non subscribed account and didn't have it show up so we obviously have a bigger problem with the list at the moment. -- 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 14.06.2018 10:07, Per Jessen wrote:

Simon Lees wrote:

...

On 14/06/18 15:42, Stefan Seyfried wrote:

...

On 14.06.2018 02:34, Simon Lees wrote:

...

, so far there has only been one example (that didn't actually make it to the list because the list settings were wrong),

Hi Simon,

Yeah, I forgot to permit posting from non-subscribers.  It _was_ in the initial request, mea culpa.

...

...

I have sent 15 mails to opensuse-bugshare, requesting 14 bugs to be opened (one duplicate). Does this mean, none of my 15 mails reached the list?

Prior to my fixing the setup, your postings would have been either denied or moderated pending approval, in both cases you would have been notified.

I have gotten no notifications.

...

...

Will I get any reply after submitting a mail to opensuse-bugshare@?

I can't remember if the mail system gives an automated reply or not in this case Per CC'd may know.

No, there is no automated reply when a posting is permitted.

Ok, thanks. Will I get an answer if the mails are processed by a human (no matter the outcome)? Or will I have to monitor all the bugs manually? (This was also in my original question, not answered by mails from Richard or Simon AFAICT).

...

What I can say is that as a subscriber to that list I haven't received any emails from you and generally the mailing list software will tell you if it was unable to forward your email to the list, so the fact I have not received the emails and you have not received a failure to send notice means something strange is up. How long ago did you send the emails?

I see Stefan's mails on June 11, but they only sent to one subscriber. Yourself and Oliver were accidentally subscribed to the nomail- version .... sorry, cut&p... uh, command line editing.

So should I resend them? Or are they in the decision-maker's queues already? -- 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 14/06/18 18:56, Stefan Seyfried wrote:

So should I resend them? Or are they in the decision-maker's queues already?

Like magic they have now appeared in my inbox. So no need to resend them. -- 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 14.06.2018 09:17, Simon Lees wrote:

I can't remember if the mail system gives an automated reply or not in this case Per CC'd may know.

It would be useful.

What I can say is that as a subscriber to that list I haven't received any emails from you and generally the mailing list software will tell you if it was unable to forward your email to the list, so the fact I have not received the emails and you have not received a failure to send notice means something strange is up. How long ago did you send the emails?

monday morning, 2018-06-11, 06:00-07:00 UTC monday evening, 2018-06-11, 18:30-18:45 UTC No bounces / spam messages in my googlemail account.

If you had mentioned you had sent emails and were wondering if they had been received in your initial mail this probably would have saved a bit of time, for example it seemed to me that Carlos answered your question in the best possible way from the info I had at the time.

My question was "will I get an answer?", because I'm not usually assuming broken setups ;-)

I also sent an email from a non subscribed account and didn't have it show up so we obviously have a bigger problem with the list at the moment.-- 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 30/06/18 19:55, Oliver Kurz wrote:

On Friday, 29 June 2018 20:01:30 CEST Stefan Seyfried wrote:

...

Am 28.05.2018 um 16:46 schrieb Simon Lees:

...

In order to make this process slightly easier and more formal during las weeks board discussion the board decided to the mailing list opensuse-bugshare@opensuse.org where community members can send an email then a volunteer SUSE employee can read the bug report then either open it or provide a summary.

So far, i requested much more than 20 bugs to be opened. None of them has been opened. I received short summaries for 9 bugs, but that's not the primary wish (a least not mine). I would really like to see the technical details.

So for now this initiative has failed big time for me.

Well, even though *I* can access the bug details with my SUSE account I simply technically *can not* make the bug public. I assume it's the same situation for Simon.

Yes something has changed in bugzilla so there are many places that we no longer have permission to make something public like we used to, I will raise this with Richard to raise with SUSE in the next openSUSE board meeting. In the mean time you will have to live with summaries, although in most cases with the issues you raise there was not much discussion in the bug reports and when there was it involved customers and would have remained private. The idea of this service wasn't for users to send in a list of multiple bug numbers everytime they get a new maintenance update, it was to help the people doing openSUSE development that need some missing info that's in a closed bug, although we will try and get to requests like that as we can anyway. But this service won't scale to that if multiple users start requesting multiple bugs. As I said in my previous email SUSE is aware this is an issue and is working to make this better in the medium to long term as they undergo various tooling changes that they have planned anyway. But until then what you have is the best we can do. -- 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