On Tuesday, 29 May 2018 7:34 Richard Brown wrote:
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.
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.
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. "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. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org