|
Description
Roke Julian Lockhart Beedell
2025-06-03 18:16:33 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. (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! 😅 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. (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 Created attachment 182132 [details] Comparison: https://bugzilla.mozilla.org/show_bug.cgi?id=1961606#module-security-title:~:text=Confidential%20Mozilla%20Employee%20Bug%20(non-security) Created attachment 182133 [details] Comparison: https://sourceforge.net/p/opencamera/tickets/new/#w-91.private:~:text=Labels:-,Mark%20as%20Private,-Updated:%20Now 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. 🐛🧹 ⚠️ 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! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |