changing how apport handles master bugs with private data

Robert Collins robert at ubuntu.com
Mon Apr 18 18:59:44 UTC 2011


On Tue, Apr 19, 2011 at 6:42 AM, Bryce Harrington <bryce at canonical.com> wrote:
> On Mon, Apr 18, 2011 at 09:53:56PM +1200, Robert Collins wrote:
>> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
>> has a summary in it of a chat pitti and I had on IRC about the
>> handling of master bugs with private data. What we currently do
>> consistently confuses users and prevents Launchpads duplicate bug
>> detection working properly (because the master bug cannot be seen).
>>
>> The basic proposal is:
>>  - the master bug should be a public bug
>>  - there should be a link in the description for easy access by
>> developers to a private-master which has the confidential data
>> [crashdumps etc]
>>  - apport should do this automatically.
>>
>> More details in the linked bug; we'd appreciate any
>> concerns/feedback/improvements folk can offer.
>
> Sounds overly complicated.  Why not just set the crash dump attachment
> as private?

Privacy is set on bugs not attachments; setting it directly on
attachments would entail considerable complexity - for instance, who
should be able to see the content of such an attachment, and how would
you add people to that list? Using the bug's subscribers wouldn't work
because on a public bug anyone can subscribe - it wouldn't grant any
privacy at all.

Complexity here would have various overheads - over and above the code
changes, the UI would almost certainly be deeply affected as it would
have to expose this complexity, and we would have to educate (via LP)
users about how this works.

I'm not going to say 'we cannot do it' or even 'we should not do it',
but I will say - its probably at least a fortnights work if not more
from a development squad to do an acceptable implementation.
Particularly once you factor in all the UI changes, data migration,
dealing with the inevitable bugs, timeouts, user support once its live
and last but in no way least, user testing [particularly important
when dealing with changes that affect accidental/deliberate disclosure
of confidential information].

-Rob



More information about the ubuntu-devel mailing list