private master bugs are confusing and lead to more duplicate filings

Bug #764414 reported by Robert Collins
416
This bug affects 81 people
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: apport

Apport currently tracks the master bug as a private bug visible only to Ubuntu developers (bugcontrol) and makes duplicate bugs public after stripping their data.

This works well but has some downsides:
 - Launchpad cannot show the master bug to folk reporting bugs via apport (so they file new bugs always)
 - After users file a new bug apport detects its a duplicate and then they cannot see the master bug and get frustrated.

It would be nice to have:
 - the master bug be public so that reporters of dups can see it in the dupe finder and can see if a dupe is detected post-filing.
 - Developers still have easy access to the raw crash data.
  - One way to do that that does not need much development would be to have a private bug exist, linked from the master bug (e.g. with a comment or in the description; something like 'Confidential crashdump for this bug is attached to bug 12345 - only visible to Ubuntu developers').

One way to achieve this is to have apport file a new public bug to be the master. This would have the necessary metadata and would include the link to the private bug + gather all the duplicates to itself. One downside is that Apport would appear to be the bug reporter for all crashdump based bug reports. That's not necessarily a bad thing, but it may confuse people.

Another way would be to have apport file a new private bug, move the attachments over from the original bug, add explanation and metadata in the description, subscribe bugcontrol and then sanitise the original bug report the same way it sanitises public bugs today. This would make the original bug be the public master, preserving the date of filing and the reporter. OTOH large files would need to be shuffled around and this might be unreliable.

Martin Pitt (pitti)
Changed in apport (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
assignee: nobody → Martin Pitt (pitti)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

-1 to the proposed solution. I think it adds more problems than it solves.

However, I agree with the premise that private apport crash reports could use some improvements.

1. Stripping of private data (core dumps) to make bug public. This has the problem that _sometimes_ you want to re-examine the core dump (such as if the retracer failed or you want to poke around more interactively via gdb.)

2. Setting bugs private when there is no actual private data present. Apport follows a "better safe than sorry" approach to keeping personal data private, but in practice this is needed in a very small fraction of the cases. But perhaps by sharpening our pencil we could make apport a bit smarter in differentiating when a bug report must be private? By simply making fewer bug reports private, this would more directly reduce the scope of the original problem stated in this bug report.

Revision history for this message
Robert Collins (lifeless) wrote :

@bryce do you mean 'veto' or 'dislike' with that -1? If the former can you please explain the problems it adds so that we can iterate on the approach and try to solve them?

Revision history for this message
Bryce Harrington (bryce) wrote :

@robert, https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033037.html

I've received your reply on that thread; you've acknowledged the issues I raised as problems this would add. On several points you've offered some arguments, however it doesn't change my mind. My concern/feedback remains that this could result in hindering work by package maintainers. I think there are better ways to solve it, and provided a few of my own thoughts for your consideration. I don't want to engage in a lengthy debate though, so am not going to comment further.

Revision history for this message
Robert Collins (lifeless) wrote :

@Bryce I hadn't seen that before I commented - sorry for any confusion added. I'm not aiming for a long debate, merely to find the cheapest overall solution.

For folk just reading the bug report, the concerns are:
 - having potentially a two-times increase in open bugs
 - making it harder to trawl through bugs and decide what to work on
 - obscure either the reporters name or the attachments

And not mentioned:
 - closing bugs in changelogs will need two bug numbers in these cases.

I can't really assess the cost of the overhead that these things will incur.

Bryce did suggest just having apport not dupe things onto private bugs, but I don't see how that is functionally different.

Revision history for this message
Martin Pitt (pitti) wrote :

> - having potentially a two-times increase in open bugs

Not quite, I'd expect that the extra bug that apport would create to move the private attachments to would be a duplicate of the master bug. So it would add an extra dupe only, plus a link to the "data dupe" into the description.

Martin Pitt (pitti)
tags: added: pet-bug
Revision history for this message
Eduard Hasenleithner (eduard-hasenleithner) wrote :

Please take as an example #829741 and #827164 (both public) which were filed as a duplicate of #832029 (private!) by "Apport retracing service". The reminder window in the two original bug says that it is a duplicate, and you should only comment when you think it is wrong. But without seeing the "master" bug report this is not possible.

Furthermore it is strange that (judging from the bug numbers) "Apport retracing service" prefers the newer+private bug in favor of the older+public bug reports in this case.

Revision history for this message
dust (hannes-b) wrote :

error ID OOPS-00f68b83cc60b5c0598f6e8179080f8c the bug i reported was made public but marked as a duplicate to a private bug which i cant access

the bug i reported
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/908486

which is marked as duplicate of this bug but which is at private
https://bugs.launchpad.net/bugs/852967

here the message on my bug report
Apport retracing service (apport) wrote 19 hours ago: This bug is a duplicate #2

Thank you for taking the time to report this crash and helping to make this software better. This particular crash has already been reported and is a duplicate of bug #852967, so is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Please continue to report any other bugs you may find.
visibility: private → public
visibility: private → public
tags: removed: need-i386-retrace

i can not look at the other as it is marked private...

so the bug is still there...

Revision history for this message
Remco Brenninkmeijer (requist1) wrote :

different bug same problem, can't see the original bug so don't know if I can provide additional information or help in any way.
(https://bugs.launchpad.net/ubuntu/+source/nux/+bug/926769)

No way to help, no way to know if my issue will be fixed, no way to see if there are workarounds. Not very elegant indeed, I hope a fix will be made.

Revision history for this message
Tony Mugan (tmugan) wrote :

Same issue here.

Very confusing to the submitter as to what has happened.
I suspected it was a temporary dummy-spit from Launchpad and was considering resubmitting as a natural reaction.

I'd like to be able to track the duplicate obviously in case I can provide some useful test info when the Fix is committed.

Revision history for this message
Paul (i41bktob-launchpad-net) wrote :

Per comments #6, #7, and #8, the code that generates the duplicate notification email should check whether the recipient's account has access to the original bug.

I still can't see the master bug report for my bug, despite that mine is now public. This decreases the number of people who can potentially fix any given issue, not to mention all the problems already listed, like the wasted effort of reporting bugs that already exist in the system.

Revision history for this message
dino99 (9d9) wrote :

hi Martin,

got a aptd crash on Precise i386 today, and apport identify it as a duplicate of bug #639616 (wow so old one), seems too funny but not serious, LTS coming out soon.

Hopes that "whishlist" does not mean "never looked". Of course that mysterious bug #639616 cant be checked, probably a private one.

Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

I've just hit this same problem on submitting bug #975939.

There seems to be an assumption that a crash dump always contains data that must be kept private. That isn't always true. If I'm testing a beta and doing it on a scratch pc, even my login info is fake and would not be a security risk if revealed in the dump.

Revision history for this message
Remco Brenninkmeijer (requist1) wrote :

wouldn't the problem be solved if a private bug would only fence off the attachments and leave the comments open? Now everyone can see what the bug is about and check if it is the same bug they are troubled by while all sensitive data remains protected.
As long as nobody is using the bugtracker as a chatbox I would not know why comments need to be private? :)

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 764414] Re: private master bugs are confusing and lead to more duplicate filings

That would be an unsafe and confusing UI. Unsafe because if someone
pastes in private data from the private attachments, disclosure would
occur. Confusing because being able to see the bug but not the
attachments referred to in the bug is confusing.

Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

#14, @Robert. Someone who has access to private data and is irresponsible or careless is always a danger, no more in this than any other scenario. Obviously private attachments would need to be clearly marked as private.

Why would it be confusing to have attachments marked 'private'? Private means 'private', if someone's confused by the word they can find a dictionary! A private attachment is no more confusing than a private bug. And having public bugs marked as duplicates of private bugs is a LOT more confusing and irritating.

Remco's suggestion (#13) looks excellent to me.

What is really holding back change in this area? Is it the ideas that are not deemed fit for purpose, or is it lack of resources to improve Launchpad?

Revision history for this message
Robert Collins (lifeless) wrote :

Someone needs to fix apport, which we have determined is the root
cause of the problem; once apport is fixed, we can consider prevent
marking duplicates across visibility boundaries.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

(Preventing public duplicates of private bug reports is bug 396406, discouraging it is bug 943497, and presenting it better is bug 434733.)

Vincent Ladeuil (vila)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

For the record, http://errors.ubuntu.com is working really well these days, and is the designated successor of using LP bugs. It solves the privacy issue in a different way.

Changed in apport (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
Revision history for this message
Eduard Hasenleithner (eduard-hasenleithner) wrote :

I'm not saying that the problem is easy to solve, but currently errors.ubuntu.com do not solve it for me. I get the message:

"Sorry, you are not a member of a group that is allowed to see the data from error reports. A non-disclosure agreement is being written that will allow for wider access."

I doubt I will be eligible for viewing sensitive data. The main problem is still that when observing a problem I have no means of checking if it already has been filed.

Revision history for this message
dino99 (9d9) wrote :

Confirm that loging with our usual login/password on errors.ubuntu.com fail with the error posted above (#19)

Revision history for this message
Thomas A. F. Thorne (tafthorne) wrote :
Download full text (3.6 KiB)

I would like to +1 the idea of a
  > A. Public master bug
However I do not think is a job that apport could be expected to do safely. It cannot interpret what data is safe to make public, what summary would be helpful to future reports trying to determine duplicates or what should go in the description (besides some attribution to the private bug that was (or is) the head bug still.
> Trade-off is all crash bugs appear to be filed by apport.
Not if a human has to create it as I suggest.
> Further, both alternatives have the additional trade-off that there are two bug reports filed for each crash bug.
We are already talking about duplicates, so there are probably multiple bugs reported anyway. Most or all of them get marked as duplicates by machines. What users are asking for is some public data to be made visible. A new top level public bug that other bugs (private or otherwise) can be made duplicates of is one bug being raised by one person once. That is a small increase in workload for what I think could lead to a big improvement in user experience and possibly less future work for the maintainer.

Having one public bug at the top of all the duplicates will allow maintainers to publicly ask for any other diagnostics they might find helpful from users. Currently people reporting duplicates hit a dead end where they can be of no use. There is no way for a maintainer to ask them all to do something helpful ( though I expect maintainers with special permissions could go to every duplicate bug and post a message to each one in turn, which sound like a lot of work). Maintainers could also publicly provide a work around, an explanation of the problem, a fixed-in status, a first know affected version and a lot of other data that people cannot currently see.

The benefit for users is that instead of seeing Not Permitted they can get some useful data. They could see if the bug their is allegedly a duplicate of is fixed. They might be able to confirm that it does seem like a duplicate (do maintainers have to do this at present? They are the only ones who might have permission to). They can ask questions, possibly view other duplicates of the same bug (which might be public) and could have helpful details in.

>It would double the quantity of bug reports they need to manage, and either obscure the reporter's name or obscure the attachments.
I suggest not moving the attachments. Give maintainers a "Make Public Head Bug" button of some kind that does some of the heavy lifting (e.g. moves duplicates to the new bug, adds link to old private head bug, adds a list of know duplciates?). They have to press one button, make one title and one public summary and that is all. For that they possibly get better data from their users.

>> After filing, apport sometimes marks bugs as dupes of a master private bug, which the dupee can't view.
> This does sound like an annoying problem. In practice I've not seen this happen that much.
It is a very annoying problem and at present it feels like it happens to me a lot. That might be because I am using the LTS release with bug reporting enabled, which is not the norm.

I hope that some o...

Read more...

jose (josekm36-j)
Changed in apport (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
dino99 (9d9) wrote :

changed to "in progress" as im not able to set it back to "triaged"

Changed in apport (Ubuntu):
status: Fix Committed → In Progress
Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

Would 'Confirmed' be a more appropriate status than 'In progress'?

Indeed, given that this bug was reported over 5 years ago, even mentioning the word 'progress' carries a touch of irony. :(

Revision history for this message
C de-Avillez (hggdh2) wrote :

reverting to Triaged.

Changed in apport (Ubuntu):
status: In Progress → Triaged
Revision history for this message
Alistair Buxton (a-j-buxton) wrote :

This bug happened to me today. I found an easily reproducible bug in a package, so because I am a helpful person, I did a fresh install just to repro it in +1, and submitted a core dump through apport. Because I knew for a fact that there was no private information in the clean install I set my bug to public. Apport then marked it as a duplicate of a private bug which I cannot access.

Revision history for this message
Karl Fogel (kfogel) wrote :

+1 on @tafthorne's suggestion in comment#21 that there be a widget that a maintainer can use to easily swap a private master bug with some chosen public duplicate bug. (Actually, nothing about this widget is specifically about private vs public, but I'll talk about it in those terms here, since this is the current driving use case.)

This widget could be accessible from both the private bug and any public bug marked as a dup of the private bug. Since private->public is a one-to-many relationship here, in the private bug the widget would allow you to select *which* public bug to make be the new master; all current other dups pointing to the private bug could even then be changed to point to the public bug as their new master as well. From the public bug, it could just be a button whose effect is: "Make me the master, thus stealing masterdom from the private bug I'm currently marked as a duplicate of."

Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

@kfogel: really? Is that what tafthorne's suggestion was? Well, in that case, I agree, that's brilliant.

@tafthorne: why did I not realise how brilliant your suggestion was? Simple. Because its length made me mutter 'tl;dr' and skip on to the next. Please, if you're going to make further brilliant suggestions for Ubuntu, MAKE THEM SHORT!!! ;)

This bug report is approaching its 6th anniversary. Can we hope for progress?

Revision history for this message
Karl Fogel (kfogel) wrote :

Hey, @ubuntu-johnwash. I agree @tafthorne's comment was long, but it also went into more detail than mine (mine left some steps as "exercises for the reader"). I'm glad I was able to summarize the key part for you :-).

Yes, would be nice if a maintainer wanted to pick this up. I don't have any insight into their priorities, and don't have time to work on the patch myself, though.

tags: added: rls-hh-incoming
tags: removed: rls-hh-incoming
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers