On 29/05/18 18:09, Richard Brown wrote:
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"
I don't think this will be the case (as someone who works on security bugs), by obs's public nature no work happens on embargo'd security bugs in obs until after the embargo has been lifted at which point someone from the security team has generally already made the bug public (the security team is really good at doing this). -- 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