marking public bug as duplicate of private bug leads to confusing UI

I can confirm this bug.

I am the upstream developer for WiFi Radar in universe/net. I have subscribed to WR bugs in Ubuntu because I am interested in supporting Ubuntu users. But not as the system is working now. There are reports coming from apport that are duplicates of private bugs. I am currently ignoring these duplicate reports since I don't want to spend all my time repeating myself.

Unfortunately, I do not even see who I can contact about the private bug because everything but its bug number is private.

I know that the bug has already been triaged and that there's a nice "Affects me too" feature meant to replace "Me too" posts like this.

A mail in my inbox just stated that bug #515257 has been marked as a duplicate of bug #513611, which I've never heard of and I can't access, even though I'm the maintainer of the package.

Is there a way to grant me the permission to access private bugs reported for the "lottanzb" package (which I maintain)? This would be a perfect workaround for this bug.

@ Severin
Please apply for Ubuntu Bugcontrol membership which will allow you to
access these private bugs. Special consideration is made for upstream
maintainers:
https://wiki.ubuntu.com/UbuntuBugControl

On 01/31/2010 03:43 PM, Severin Heiniger wrote:
> I know that the bug has already been triaged and that there's a nice
> "Affects me too" feature meant to replace "Me too" posts like this.
>
> A mail in my inbox just stated that bug #515257 has been marked as a
> duplicate of bug #513611, which I've never heard of and I can't access,
> even though I'm the maintainer of the package.
>
> Is there a way to grant me the permission to access private bugs
> reported for the "lottanzb" package (which I maintain)? This would be a
> perfect workaround for this bug.
>
>

Today I forwarded a new (for me) bug report #602160. For unknown reasons it was created as "private". Then I marked it as "public".

After a few seconds (!) Launchpad notified me that this bug was marked as duplicate of bug #597612 - then I tried to access this last one to better understand the situation, but unfortunately this bug is private.

How could I subscribe it in order to read the evolution of the bug?

Sorry for my English. I can't really understand what You wrote at comment #3: should I enter the UbuntuBugControl to enter the private bug #597612 ? I read the UbuntuBugControl page, and I can say it refers to bug/software experts, not simply users like me. Should I triage at least 5 other bugs in order to access bug #597612 ? This seems a peculiar procedure to follow ...

Thanks in advance for Your help.

Ciao
CM

Cesare - that is the apport robot checking for private data in the stuff that ubuntu-bug uploads as part of filing the bug. The apport system then detected that your bug was a duplicate, but the thing it is a duplicate of is still private for some other reason.

Sorry for the noise.

I am escalating this bug because Lp is creating links to pages that will 404 for the user. Lp is still showing a link to the private bug above the comment box.

I'm glad this is escalated, but i suspect that a full fix is out of
scope until the main disclosure work - because we need to get the root
cause - handle things like:
 - asking the user if they want to grant visibility to the filer of
dupes (many may be moved at once due to the many-dupes changing case)
 - or asking them if they want to close the dupes (bugstatus
duplicate, duplicate-of set to the master, but they cannot see any
info)
 - etc etc etc
 - we may even need bug relationships to solve this really well - have
a private bug, and a public bug with a bugrelationship of 'depends
on', and have the dupes be made against the public bug.

So I suggest we degrade the bug back to high, that the disclosure work
include this in it, and the short term fix (do not generate links) be
done trivially.

Somehow the Bug #757305 marked as a duplicate of unknown (private?) Bug #757280. It's about gnome-language-selector crashing with language-pack dependence errors. I don't want to post details about that here and want to report that this is a bug of launchpad itself as it seems :(

I do not see this as in scope for disclosure. This is not just about confidential private data, this is also about confidential personal data. 95%+ percent of the affected users cannot access a the master bug because the bug was automatiically marked private because the the attachments may contain personal information.

The root issue is not about granting users access. Launchpad has been making links that are 403 or 404 for the user. Launchpad is mean and it must be punished. I think the underlying problem here is that it was assumed that we could change from 403 to 404 because there were no bugs with the UI, which is certainly not true.

It is clear from the user comments on this bug, the dupes, and from IRC conversations that Launchpad is setting bad expectations. Fixing this bug entails explaining the situation:
a. User can access the bug, explain the bug is a duplicate and provide a link
b. The user cannot access the bug, explain the bug is a duplicate of a private bug, show the number (do not link).

bug 743269 and bug 762747 are another example. Particularly annoying in this case because I cant see the resolved symbols of the stack trace on the public bug, because by chance the private one was filed first.
How about this:
If there is a private bug and a public bug that are dupes, why not marking the private one a dupe of the public one, regardless of which came first?

It occurs to me that automatic marking of earlier private bugs as duplicates of later public bugs might be a problem if significant work had been done in the earlier private bug. Generally speaking, automatic (rather than human-mediated) marking of older bugs as duplicates seems like it might get in the way of developers using the bug tracker.

In the meantime, can it be so that we don't get a "Error: Page not found", but an explanation that this is a private bug and you are not allowed to see it?

Shouldn't be that difficult to change.

The reason this happens a lot is a design choice in apport's backend.
I think that fixing that will cause most of the frustration to go
away.

r12847 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12847) is part of this bug's fix.

The change in Jon's branch is deployed, the underlying problem is however much more extensive, so putting the bug back to that status.

Is that in regards to having:

In the meantime, can it be so that we don't get a "Error: Page not found", but an explanation that this is a private bug and you are not allowed to see it?

?

Stating there is or is not a private bug violates the existing rule that private aretfacts do not exist for non-privileged users. One could argue that the bug though is compromised. It has been placed in a public relationship (duplicate) and and the id may be known and nothing more.

I think the proper fix for this bug is bug 777797. I want to close this bug when the 404 and 403 page text is updated.

Hi guys!

I was led to this bus by trying to report something like bug #396406.
I just wanted to add that UI itself is not an issue in this case. The issue is that the bot closes open bugs in favor of private. And as a reported I cannot even know whether the bug is going to be fixed or it will be closed as invalid after the reporter is unable to provide additional info. I often do some researches on bugs I report and I'm not sure this information is going to reach the developers.

So now I keep reopening my public bugs closed as duplicates of private ones. Could you please consider bug #396406 more thoroughly?

As you have noted, the apport bug does this - bug 764414 discusses how to change that behaviour.

We have a new pattern that might be employed to close this bug. Lp can show users the identifying info to users with limited view. Instead of showing a 404, Lp could show the bug title, project displayname and icon, with a message explaining that the rest of the information is not shared with the user. bug reporters, or affected users would be granted limited view. I think we need to discuss the rules for showing bug titles. Most private bugs have titles made by apport, but some are made by humans. I think these are generally safe to show. They are not disclosing user data. Security bugs probably do have meaningful titles, but I also image that the duplicate bug also has a meaningful title and the user knows it is a security issue...I doubt letting the user see the master bug title compromises data. We may not want to permit bugs to be duplicates of proprietary bugs, at least not until bug linking/relationships is complete.

I think that that pattern would be a reasonable compromise; certainly
a nicer experience than the 404's. We need to make sure we don't leak
data like we did before we tightened up the access rules and removed
the removeSecurityProxy special casing that traversal was doing.

I don't think we should show the title, because we cannot know if it
is an apport title or if the user helpfully put their phone number in
it.

That should make it safe to be a dupe of a proprietary bug too.

-Rob

The templates and views really want to show the bug title, in fact I see the view is one of those pages that violates the pagetitle and breadcrumb rules. Since it really wants to own the bug title, it will have to take the extra responsibility to sanitize .page_title and .bug_title_edit_widget I think the JSON Cache will also need sanitising. The head_epilogue will not render so we do not need to concern ourselves with that.

Their may be fast and slow way of knowing who has limited view on the bug.
Everyone gets limitedview if one of the dupe bugs is public
Some people get limitedview if they are subscribed to a duplicate private bug.

r14855 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14855) is part of this bug's fix.

Today I filed bug #975939. Shortly afterwards apport added "This particular crash has already been reported and is a duplicate of bug #954736, so is being marked as such." OK, fine. But that's an automated service, and since #954736 is private, I have no way of confirming whether it really IS a duplicate.

Additionally, there is a huge irony, since apport adds "Additionally, any further discussion regarding the bug should occur in the other report.". Great. :( How the [ahem] do I do that, if the other bug is private?

Wouldn't it be far more useful if the OTHER bug is marked as a duplicate of the public one? Then likewise any further bug reports that apport believes are duplicates of #954736 would instead also be marked as duplicates of the public one.

People here seem to be focussed on whether to give a 403, a 404, a more friendly report, etc etc, yet there is a far more fundamental problem, namely how reporting of duplication is organised.

I was going to ask if this topic is appropriate for this bug, or should I be opening a new one? But then I found #396406, which is absolutely spot on, but has been closed (!!!) by referring to this bug.

John, Launchpad can't show you the bug -- that would be leaking information that users have said is private. This bug is purely about making that situation slightly clearer. You probably want bug #764414, which asks apport to not create this situation in the first place.

@William, I know and understand that bug is private. Note that it may not be that the user has explicitly said it is private. I was surprised to notice (by chance) that my own bug was private when I submitted it, and had to mark it public myself. Subsequently the system stripped my crash dump, but since this was a test machine there was nothing confidential in the dump. How many bugs are marked private where in fact they could have been public? (rhetorical question, of course. no way of knowing)

Would it be possible to have maybe just the summary and title of the bug as public? and the rest private?

@IKT

Not at this time. We do not know how to hide the summary or title, and the information is copied to bug history which does not have a mechanism to know which information is private because the summary or title was edited.

The real problem here is that users should be creating public versions of bugs. I would like to make it impossible for anyone to make a public bug a duplicate of a private bug. Apport complicates the matter; it is not a person, it does know how to create a public bug report from a private report, and it does not care that it hurt people.

@Curtis
"I would like to make it impossible for anyone to make a public bug a duplicate of a private bug. Apport complicates the matter; it is not a person,"

Apport is not a person, but why not have it work according to the same rule you propose for people? The real problem is that Apport is making duplicates in the wrong direction. If two bugs are believed similar, the private one should refer to the public one, not the other way round. And all subsequent discussion/updates/etc should be on the public one.

apport is not a part of launchpad. Someone connected with Ubuntu need to fix the Apport, otherwise Ubuntu's bug management will break, and Lp's will be inundated with 1000s of oopses every day.

As a workaround, how about having Launchpad generate a placeholder for any private bug which has duplicates?

Let's say bug 123 is private, and bug 234 is marked as a duplicate. Now the system (or in the absence of automation, a maintainer) creates bug 235, and marks both 123 and 234 as duplicates of that, perhaps with just a placeholder to say that "this is a bug which has private duplicates; but have a look at the public duplicates until somebody manually fixes this bug description".

I fail to understand the logic of adding a link to a private bug report in a public bug report. Since there is the expectation that if I see a link, I can read the page/document it links to.

I have an issue in 12.04 where my Huawei E220 USB modem will not connect. 12.04 does not even mount it. I did a search on Google using the error message I got "modem-manager crashed with SIGSEGV in g_utf8_validate()". I found a number of bug reports which some bright spark at Launchpad.net closed and inserted a note referring to bug #952941, which I have been advised is a private bug which I cannot read. This is unacceptable.

I feel very strongly that I should be able to see what progress, if any, has been made in resolving the bug. To date I have yet to find a solution to this issue. There is no post anywhere that advises that this bug is being worked on and what the progress is. At the very least I expect some public feedback/acknowledgment of the issue and what is being done to resolve it. I do not need to know the contents of any private emails/memos/messages being circulated between those that are, hopefully, looking into it.

I would appreciate it if someone can give me some feedback on my issue or where I can go to read it. I have logged a query on my issue on the ubuntuforms.org and linuxquestions.org forums. So far the only response I received was from the good folks on linuxquestions.org.

Hi

I wish to clarify the last paragraph of my previous post. It might be a little ambiguous. I basically would like a link to a bug report that I can read on my bug.

Everyone agrees that you should be able to the master bug that your bug was made a duplicate of. The problem is that some people and the Ubuntu apport bot are complete and utter inconsiderate bastards. Fixing this is difficult because it will break Ubuntu's bug management. Ubuntu needs to change its bot.

See http://blog.launchpad.net/general/bug-linking-part-2 which discusses the special cases needs to support duplicates properly.

I have encountered this many times. Often when I report a bug it is marked of another one as a duplicate, then I want to read if there are workarrounds but I cannot.

For me it would be very helpfull, if there would be an option, to subscribe to a private bug and get all comments once it goes public.

Felix wrote:
> I have encountered this many times. Often when I report a bug it is
> marked of another one as a duplicate, then I want to read if there are
> workarrounds but I cannot.

maybe we just take matters into our own hands and just find the oldest public duplicate and start posting our bug # links, observations, and work-arounds to that.

Whow, a Bug-Report from 2009 which still isn't resolved even though it's importance is at "High" and was at "Critical" inbetween.

Is there any way of forcing apport to submit a bug-report?
See https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1225207 for details, short story:
Apport dosn't even let me upload my bug-report. I couldn't find a "force this thing to upload"-button and so my only option would be to write to launchpad-support and asking them to "unprivate" the bug I have a duplicate of.

How should a user handle this? Is contacting launchpad-support the way to go? Shall I create an bug via the Website and try to post all apport-/generated files myself?
And if my bug-report is marked as a duplicate (by a bot): Should I click the "is not a duplicate" button so my report gets human-reviewed?

On 14/09/13 16:59, Simon K wrote:
> Whow, a Bug-Report from 2009 which still isn't resolved even though
> it's importance is at "High" and was at "Critical" inbetween.
>
> Is there any way of forcing apport to submit a bug-report? See
> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1225207 for
> details, short story: Apport dosn't even let me upload my bug-report.
> I couldn't find a "force this thing to upload"-button and so my only
> option would be to write to launchpad-support and asking them to
> "unprivate" the bug I have a duplicate of.
>
> How should a user handle this? Is contacting launchpad-support the
> way to go? Shall I create an bug via the Website and try to post all
> apport-/generated files myself? And if my bug-report is marked as a
> duplicate (by a bot): Should I click the "is not a duplicate" button
> so my report gets human-reviewed?

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414 is the real
bug that yours is a duplicate of. Ubuntu's apport tool shouldn't be
forwarding users to bugs that it knows are private.

Launchpad support can't do anything here; it's a matter for those who
manage Ubuntu's bugs. It's not clear that this is a bug in Launchpad at
all, since we can't make a private bug public just because someone
marked a public bug as a duplicate.

@wgrant: Of course you can't make a private bug public just because someone marked a public bug as a duplicate. But see my comment #28 to you. Bugs are being unnecessarily marked private in some cases. And non-confidential attachments are being unnecessarily stripped.

This leads to a system where only the privileged developers can investigate bugs.

On 15/09/13 20:53, JohnWashington wrote:
> @wgrant: Of course you can't make a private bug public just because
> someone marked a public bug as a duplicate. But see my comment #28 to
> you. Bugs are being unnecessarily marked private in some cases. And
> non-confidential attachments are being unnecessarily stripped.
>
> This leads to a system where only the privileged developers can
> investigate bugs.

That's what bug #764414 is about: the problem is that apport is creating
awkward relationships with private bugs. That's not Launchpad's fault.

Wherever the fault lies, can we focus on getting it fixed, rather than saying "not x's fault, not y's fault, not..."? Another week and it will be 4 years. What is needed to get this fixed, rather than playing pass the parcel?

The people who can fix it are the apport developers, not the Launchpad developers. So commenting on the Launchpad bug will do no good.

OK William, I take your point, I added Apport to the projects this bug affects. I hope that's the right thing to do.

Personally I wouldn't like to bet on which project is relevant, I feel some design work is needed to fix it, so perhaps more than one set of people is needed.