Bug 505177 - Permit reporters to restrict the visibility of their to-be-published BZ tickets to Developer and Triager team members.
Summary: Permit reporters to restrict the visibility of their to-be-published BZ ticke...
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: bugs.kde.org
Classification: Websites
Component: code customizations (other bugs)
Version First Reported In: unspecified
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: KDE sysadmins
URL: https://discuss.kde.org/t/can-a-kde-b...
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-03 18:16 UTC by Roke Julian Lockhart Beedell
Modified: 2025-07-18 09:39 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Comparison: https://bugzilla.mozilla.org/show_bug.cgi?id=1961606#module-security-title:~:text=Confidential%20Mozilla%20Employee%20Bug%20(non-security) (4.96 KB, image/png)
2025-06-09 22:57 UTC, Roke Julian Lockhart Beedell
Details
Comparison: https://sourceforge.net/p/opencamera/tickets/new/#w-91.private:~:text=Labels:-,Mark%20as%20Private,-Updated:%20Now (1.99 KB, image/png)
2025-06-09 22:57 UTC, Roke Julian Lockhart Beedell
Details
Comparison: issuetracker.google.com (34.65 KB, image/png)
2025-06-18 16:32 UTC, Roke Julian Lockhart Beedell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roke Julian Lockhart Beedell 2025-06-03 18:16:33 UTC
SUMMARY

Currently, unlike at RHBZ and Mozilla Bugzilla, there is no way at KDE's instance to mark a bug (or comment) as restricted, which means that when information that should not be broadly public is necessary to diagnose a bug, it must either be shared manually via e-mail (like security@kde.org, which is insecure, and difficult to triage at scale) instead of being done via Bugzilla.

STEPS TO REPRODUCE

Visit https://bugs.kde.org/enter_bug.cgi?classification=I%20don%27t%20know, or report a crash via `plasma-drkonqi-6.3.5-1.fc42`.

OBSERVED RESULT

At https://bugs.kde.org/show_bug.cgi?id=505130#c7, I was forced to send material via e-mail to an Okular developer, when it would have been significantly more beneficial, especially for the nominal assignee, to have it on hand for all developers interested.

EXPECTED RESULT

Like in GNOME Abrt (on Fedora), there should be a checkbox to restrict access to those in the https://invent.kde.org/teams/bug-triagers or https://invent.kde.org/teams/kde-developers teams, just as Sentry does.

ADDITIONAL INFORMATION

https://www.mozilla.org/en-US/about/governance/policies/security-group/bugs/#other:~:text=Besides%20the%20permanent%20security%20bug,and%20when%20that%20makes%20sense states:

“	Besides the permanent security bug group members described above, there are two other categories of people who may participate in security bug group activities and have access to otherwise-confidential security bug reports:

	• A person who reports a security bug will have continued access to all Bugzilla activities associated with that bug, even if the bug is marked “Security-Sensitive.”

	• Any other persons may be given access to a particular security bug, by someone else (who does have access) adding them to the CC list for that bug.

	Thus, someone reporting a security bug in essence becomes a member of the overall group of people working to investigate and fix that particular vulnerability, and anyone else may be easily invited to assist as well if and when that makes sense.

Similar information is available in https://bugzilla.redhat.com/page.cgi?id=faq.html#data-category-confidential:~:text=group%20set%2C%20etc.-,Confidential,every%20Data%20Category%20except%20Public.,-Personally%20Identifiable%20Information.
Comment 1 Ben Cooksley 2025-06-04 11:56:00 UTC
Is there a particular use case for this? We've always stated that security bugs should be reported outside of Bugzilla to security@kde.org.
Comment 2 Roke Julian Lockhart Beedell 2025-06-04 12:02:43 UTC
(In reply to Ben Cooksley from comment #1)

Some bugs aren't security bugs, but do include material (like personal information) that shouldn't be publicly available. Being able to share such documentation, when it's integral to bug reproduction, with the relevant developers would be very useful, since there's a lightyear of trust difference between those in the aforementioned teams versus merely the general public. As it is, this has to be shared via e-mail instead.

In an example cited, I needed to share a document with an Okular developer. It wasn't a security bug: just a very reproducible crash that prevented me filling the document with Okular. However, due to the nature of the document (it involved personal information), I couldn't just share it publicly.

Likewise, say that visiting a pornography site caused a crash in Falkon: I would imagine that the user wouldn't want to disclose this in Dr Konqi's GUI unless they knew it would be marked as private. I've had that happen once to me, using Mozilla's Fenix for AOSP. It was embarrassing enough reporting it confidentially! 😅
Comment 3 Ben Cooksley 2025-06-06 07:45:11 UTC
Personal information should never be published on KDE Bugzilla, as the email stream is publicly archived via kde-bugs-dist. It is also preferable that we don't have that type of information stored within the Bugzilla database as it then is subject to future removal on request which is not trivial to do.

Having the information be reported to the investigating developer individually is therefore preferable as the individual has explicitly chosen who they disclose the information.
Comment 4 Roke Julian Lockhart Beedell 2025-06-06 14:35:36 UTC
(In reply to Ben Cooksley from comment #3)

> Personal information should never be published on KDE Bugzilla, as the email stream is publicly archived via kde-bugs-dist.

That's why I propose this as a file-time flag. It would prevent it ever being posted to the mailing thread. However, I understand with your subsequent statement should nullify this. I'll ask, though, when it's necessary to solve something a crash, is not storing that data more important than getting the bug fixed? If so, then I suppose that this is WONTFIX or NOTABUG.

> Having the information be reported to the investigating developer individually is therefore preferable as the individual has explicitly chosen who they disclose the information.

As anecdotally corroborated at https://discuss.kde.org/t/can-a-kde-bugzilla-ticket-be-marked-as-private/35084/14?u=rokejulianlockhart, I've been informed by a developer that this is an unideal burden to have placed on the maintainer, [^1] because it means that they are solely responsible for remediating the bug, lest they request that the original owner share this data with other maintainers. However, that is less secure than it being temporarily stored on KDE BZ until the bug has been remediated.

[^1]: https://matrix.to/#/!aQACjulWrDEvXHTwXT:kde.org/$vF7qi9Alrb4B6rC8ap727nkjF_U9XHZM87pXuYyxKPw?via=matrix.org&via=kde.org&via=im.kde.org
Comment 7 Roke Julian Lockhart Beedell 2025-06-18 16:32:14 UTC
Created attachment 182366 [details]
Comparison: issuetracker.google.com

I've since located a much better reason, although this solely applies to attachments: When I report an issue with a KDE package for AOSP, I cannot submit an `adb bugreport` without exposing personal information to the world. You can see at https://issuetracker.google.com/issues/425896312#comment2:~:text=bugreport%2DFP5%2DUKQ1.230924.001%2D2025%2D06%2D18%2D16%2D52%2D11%2Ddumpstate_log%2D24299.txt-,Restricted,-85%20KB%20View&text=bugreport%2DFP5%2DUKQ1.230924.001%2D2025%2D06%2D18%2D16%2D52%2D11.zip-,Restricted,-17%20MB%20Download&text=dumpstate%2Dstats.txt-,Restricted,-8%20B%20View that users are expected to set these attachments as "Restricted" (which limits access to developers) due to this. There is little other way to submit a complete `logcat` (even merely `--buffer=crash`) and environment information, for an AOSP device.
Comment 8 Bug Janitor Service 2025-07-03 03:47:24 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Bug Janitor Service 2025-07-18 03:47:16 UTC
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.