From noreply at ubuntu.com Sun Jul 1 02:38:40 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 01 Jul 2012 02:38:40 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingUpdateManager=22_by_mte?= =?utf-8?q?rry?= Message-ID: <20120701023840.22331.69743@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingUpdateManager" page has been changed by mterry: http://wiki.ubuntu.com/DebuggingUpdateManager?action=diff&rev1=45&rev2=46 Comment: remove old bug links Forwarding of update-manager bugs upstream is not necessary as update-manager is only used by Ubuntu and there is not a traditional upstream. - = Known bugs = - - Description of known issues, how to recognise them and stock responses/actions. - - '''Open''' - || '''Bug''' || '''Description''' || '''Action''' || - || [[https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/107188|107188]] || Out of memory error on KDE || duplicate, no solution yet || - || [[https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/571743|571743]] || xubuntu-desktop and ubuntu-desktop can not be upgraded if installed in parallel || duplicate, no solution yet || - - - '''Triaged''' - || '''Bug''' || '''Description''' || '''Action''' || - || [[https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/721306|721306]] || Cant upgrade from 10.04 to 10.10 || Master bug || - - - '''Closed''' - || '''Bug''' || '''Description''' || '''Action''' || - || [[https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/280236|280236]] || hangs if a script fails to run || Make bug report a duplicate and ensure reporter updates to 1:0.93.22 || - - = Non-bugs = * When running a development release of Ubuntu you will frequently receive messages when trying to run update-manager that it could not calculate the upgrade. This is expected and happens due to the amount of changes occurring in the repository. From noreply+3549713526 at badoo.com Mon Jul 2 20:59:19 2012 From: noreply+3549713526 at badoo.com (Badoo) Date: Mon, 2 Jul 2012 20:59:19 +0000 Subject: Ubuntu Bugsquad, Erick left a message for you Message-ID: Erick left a message for you Only you can see the sender and content of your message, and you can delete it anytime. You can instantly reply using our message exchange system: http://us1.badoo.com/01197604776/in/UfrMtNl3Gi8/?lang_id=3&m=21&mid=4ff20ba60000000000030000d3945476 If the link in this message does not work, try copying and pasting it into your browser. This email is part of our delivery procedure for the message sent by Erick. If you have received this email by mistake, please ignore it. The message will be deleted soon. Have fun! The Badoo Team You have received this email from Badoo Trading Limited (postal address below). http://us1.badoo.com/impersonation.phtml?lang_id=3&mail_code=21&email=ubuntu-bugsquad%40lists.ubuntu.com&block_code=321353&m=21&mid=4ff20ba60000000000030000d3945476 Badoo Trading Limited is a limited company registered in England and Wales under CRN 7540255 with its registered office at 12 Red Lion Square, London, WC1R 4QD. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Mon Jul 2 20:20:23 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Mon, 02 Jul 2012 20:20:23 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingPrintingProblems=22_by_?= =?utf-8?q?till-kamppeter?= Message-ID: <20120702202023.31757.76125@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingPrintingProblems" page has been changed by till-kamppeter: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=diff&rev1=67&rev2=68 8. Check via the command <
> {{{$ file ~/printout}}} <
> what format the file is. It is usually PDF or PostScript. Display the file on the screen to see whether the problem already occurs (error message, missing characters, wrong colors, ...). If you see the problem already, the application is the culprit, assign your bug report to the application's package, otherwise assign it to the "cups" package. 9. Attach the original file of your application and the ~/printout file to your bug report. + = Problems installing the CUPS package = + + Most problems of installing the CUPS package are due to the CUPS daemon not starting after the installation or update of the package and this often happens when something is not OK with the configuration settings in '''/etc/cups/cupsd.conf'''. + + To find out what is happening during startup of CUPS run the following commands <
> + {{{$ wget http://people.canonical.com/~pitti/tmp/cups.upstart.debug}}} <
> + {{{$ sudo cp /etc/init/cups.conf{,.orig} }}} <
> + {{{$ sudo cp cups.upstart.debug /etc/init/cups.conf}}} <
> + {{{$ sudo stop cups}}} <
> + {{{$ sudo start cups}}} <
> + This should fail. Please attach '''/tmp/log''' to your bug report. After that, please restore the original script again with <
> + {{{$ sudo mv /etc/init/cups.conf{.orig,} }}} <
> + + if the CUPS daemon did not start ("lpstat -r" says "scheduler is not running") follow the instructions under "CUPS error_log" on this page and instead of sending a job try to start CUPS: <
> + {{{$ sudo /usr/sbin/cupsd}}} <
> + If it fails, attach your error_log to your bug report. + + If you look into your /tmp/log and error_log, you can probably also already find by yourself what went wrong, for example a broken entry in /etc/cups/cupsd.conf. + = Known bugs = Description of known issues, how to recognise them and stock responses/actions. From hggdh2 at ubuntu.com Mon Jul 2 22:20:15 2012 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Mon, 2 Jul 2012 17:20:15 -0500 Subject: Ubuntu Bugsquad, Erick left a message for you In-Reply-To: References: Message-ID: <20120702172015.239ceaed@xango4> On Mon, 2 Jul 2012 20:59:19 +0000 Badoo wrote: > Erick left a message for you Sorry. It seems I mistakenly approved this message (from a bunch of them from Badoo). This will not happen again, I hope: I added .*@badoo.com to the bin list. Cheers, ..C.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From noreply at ubuntu.com Wed Jul 4 12:12:42 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 04 Jul 2012 12:12:42 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingScreenLocking=22_by_mde?= =?utf-8?q?slaur?= Message-ID: <20120704121242.9017.55055@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingScreenLocking" page has been changed by mdeslaur: http://wiki.ubuntu.com/DebuggingScreenLocking?action=diff&rev1=15&rev2=16 || '''Bug''' || '''Subject''' || '''Symptom''' || || [[https://launchpad.net/bugs/411350|411350]] || gnome-screensaver not functioning || Inhibitors would not be cleaned up properly if the application that set them dropped off the bus. || + List of known issues with compiz: + + '''Open''' + || '''Bug''' || '''Subject''' || '''Symptom''' || + || [[https://launchpad.net/bugs/886605|886605]] || Desktop, Launcher and menu bar still visible when screen locked || Desktop, Launcher and menu bar still visible when screen locked || + == gnome-screensaver cannot grab keyboard or mouse == gnome-screensaver will not activate if an applications grabs keyboard and mouse focus. From noreply at ubuntu.com Wed Jul 4 14:16:44 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 04 Jul 2012 14:16:44 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?= =?utf-8?q?lson?= Message-ID: <20120704141644.30865.53546@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "MozillaTeam/Bugs" page has been changed by chrisccoulson: http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=81&rev2=82 If you are unsure whether your problem should be reported as a bug, then please ask a question in one of the above mentioned sites. Alternatively, if you would like help in your native language, you could try using the support forum of your local Ubuntu community. To find this, and other ways to get in touch with your local Ubuntu community, please visit [[http://loco.ubuntu.com/|http://loco.ubuntu.com/]]. + See also [[http://www.ubuntu.com/community/report-problem|http://www.ubuntu.com/community/report-problem]]. + == Use Apport == All Firefox and Thunderbird bugs '''must''' be submitted with Apport (unless there is another problem which prevents you from using Apport). For Firefox, you can do this by selecting the "Report a Problem" entry in the Help menu, or pressing Alt+F2 and running `ubuntu-bug firefox`. @@ -64, +66 @@ == Multiple problems == Multiple, unrelated bugs '''must be reported as separate bugs'''. Please do not use a single bug report to report or discuss multiple, unrelated bugs. If you do this, then it is highly likely that a developer will close your bug report and ask you to report the problems separately. + + == Is the problem Ubuntu specific? == + + When reporting a bug, it is often useful to determine whether the problem is specific to Ubuntu builds of Firefox and Thunderbird. In order to determine this, please try to recreate the problem in an official Mozilla build of Firefox or Thunderbird. These can be downloaded from the following locations: + + * [[www.mozilla.org/firefox/#desktop|Download Firefox]] + * [[www.mozilla.org/thunderbird/|Download Thunderbird]] + + To run these you will need to extract the downloaded tarball. Once you have done this, open a terminal and do the following: + + {{{ + cd ~/Desktop/firefox # Assuming that you extracted the download to your desktop. + ./firefox + }}} + + Obviously, for Thunderbird, replace "firefox" with "thunderbird". + + If the same problem can be recreated in the official Mozilla build that you downloaded, then you can help Ubuntu developers by reporting your bug in the upstream bug tracker. To do this, please have a read through the upstream [[https://developer.mozilla.org/en/Bug_writing_guidelines|bug reporting guidelines]]. + + == Check the Error Console == + + Some bugs may result in unhandled JS exceptions or other error messages being logged to the error console, and these may provide a strong clue as to the cause of a bug. To view these, open the error console from "Tools -> Web Developer -> Error Console", and select "Errors". + + Note, you many need to enable the menuitem to access the error console. To do this, open "about:config", and set "devtools.errorconsole.enabled" to "true" == Problems with a specific website == @@ -215, +241 @@ When reporting your bug, please also describe the scenario which triggers the problem. Does it happen on a particular site? If so, please provide a URL. Please also try disabling all of your addons (you will be asked to do this anyway, so you can save other peoples time by doing this when reporting your bug). Note that debugging memory leaks in Firefox is quite involved. If you're feeling adventurous, please take a look at [[https://developer.mozilla.org/en/Debugging/Debugging_memory_leaks|Debugging memory leaks]] and [[https://developer.mozilla.org/en/Debugging_Mozilla_with_Valgrind|Debugging Mozilla with Valgrind]] - - == Check the Error Console == - - Some bugs may result in unhandled JS exceptions or other error messages being logged to the error console, and these may provide a strong clue as to the cause of a bug. To view these, open the error console from "Tools -> Web Developer -> Error Console", and select "Errors". - - Note, you many need to enable the menuitem to access the error console. To do this, open "about:config", and set "devtools.errorconsole.enabled" to "true" == Other specific issues == === Problems with menus on systems that use a global menubar === @@ -355, +375 @@ Visit [[https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures|BugProcedures]] for an Introduction and best practices on how to process Mozilla bugs. + = Further reading = + + * [[https://developer.mozilla.org/en/Bug_writing_guidelines|Upstream bug reporting guidelines - MDN]] + * [[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html|How to Report Bugs Effectively]] + * [[http://www.ubuntu.com/community/report-problem|Report a Problem]] + * [[https://help.ubuntu.com/community/ReportingBugs|Reporting Bugs - Community Ubuntu Documentation]] + ---- [[CategoryMozillaTeam]], [[CategoryBugSquad]], [[CategoryDebugging]] From noreply at ubuntu.com Fri Jul 6 14:10:01 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 06 Jul 2012 14:10:01 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingPrintingProblems=22_by_?= =?utf-8?q?till-kamppeter?= Message-ID: <20120706141001.6724.91277@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingPrintingProblems" page has been changed by till-kamppeter: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=diff&rev1=69&rev2=70 If you look into your /tmp/log and error_log, you can probably also already find by yourself what went wrong, for example a broken entry in /etc/cups/cupsd.conf. + To restore the default configuration file /etc/cups/cupsd.conf, run the commands: <
> {{{$ sudo mv /etc/cups/cupsd.conf ~}}} <
> {{{$ apt-get download cups}}} <
> {{{$ sudo dpkg -i --force-confmiss cups_*.deb}}} <
> You can also restore other configuration files, as printers.conf for example. Simply do the same steps but instead of cupsd.conf move away the offending configuration file. + = Known bugs = Description of known issues, how to recognise them and stock responses/actions. From noreply at ubuntu.com Wed Jul 4 13:57:16 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 04 Jul 2012 13:57:16 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?= =?utf-8?q?lson?= Message-ID: <20120704135716.25032.62923@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "MozillaTeam/Bugs" page has been changed by chrisccoulson: http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=79&rev2=80 We get a lot of Firefox bug reports from Ubuntu users and the majority of those don't contain sufficient useful information to progress them further, or sometimes even understand what the actual problem is. Please understand that we don't have the manpower available to spend time on every single bug report to continually ask reporters for information that ''could'' be provided up-front. To increase the chances that your bug report attracts the attention of a developer, you '''must''' follow these guidelines. A developer will ask you for the required information that you didn't provide, so following these guidelines will save time for the person who looks at your bug report. Here are some instructions you should follow before filing a bug report: + + == Consider whether a support request would be more appropriate == + + Please only report a bug if you have identified an actual software defect in Firefox or Thunderbird. A defect is where some piece of functionality is broken, or clearly does not behave as expected. + + If you require help with using either application, or you have a question or any other problem that you would like help to resolve, then there are more appropriate resources that you can use in these cases (rather than reporting a bug): + + * [[http://askubuntu.com/|Ask Ubuntu]] + * [[http://ubuntuforums.org/|Ubuntu Forums]] + * [[https://answers.launchpad.net/ubuntu|Support tracker]] + + If you are unsure whether your problem should be reported as a bug, then please ask a question in one of the above mentioned sites. Alternatively, if you would like help in your native language, you could try using the support forum of your local Ubuntu community. To find this, and other ways to get in touch with your local Ubuntu community, please visit [[http://loco.ubuntu.com/|http://loco.ubuntu.com/]]. == Use Apport == From noreply at ubuntu.com Wed Jul 4 14:01:06 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 04 Jul 2012 14:01:06 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?= =?utf-8?q?lson?= Message-ID: <20120704140106.30889.72707@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "MozillaTeam/Bugs" page has been changed by chrisccoulson: http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=80&rev2=81 [[http://support.mozilla.com/en-US/kb/Safe%20Mode|Link to Mozilla Documentation]] + == Check if the bug has already been reported == + + Please try to make the effort to check if your bug has already been reported. We appreciate that sometimes it is difficult to know what to search for, and it may be difficult to spot duplicates in the presence of so many other bug reports. + + == Look for your problem on SUMO == + + Please have a look on [[http://support.mozilla.org/|http://support.mozilla.org/]], to see if anybody else has asked for support for a problem that is similar to your own. You may find that the problem you are facing isn't really a bug, or the problem has already been reported to developers. You may also find a workaround for your problem too. + == Be specific == Try to make sure that the developer will be able to reproduce the bug you are seeing. Provide every detail you can regarding the bug, especially an explicit statement of exactly which sequence of user actions are needed to reproduce the bug. Please don't assume that just because you experience a bug, that it will be trivial for other people to reproduce. - == Check if the bug has already been reported == + == Multiple problems == + Multiple, unrelated bugs '''must be reported as separate bugs'''. Please do not use a single bug report to report or discuss multiple, unrelated bugs. If you do this, then it is highly likely that a developer will close your bug report and ask you to report the problems separately. - Please try to make the effort to check if your bug has already been reported. We appreciate that sometimes it is difficult to know what to search for, and it may be difficult to spot duplicates in the presence of so many other bug reports. - - == Look for your problem on SUMO == - - Please have a look on [[http://support.mozilla.org/|http://support.mozilla.org/]], to see if anybody else has asked for support for a problem that is similar to your own. You may find that the problem you are facing isn't really a bug, or the problem has already been reported to developers. You may also find a workaround for your problem too. == Problems with a specific website == From noreply at ubuntu.com Wed Jul 4 14:19:53 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 04 Jul 2012 14:19:53 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22MozillaTeam/Bugs=22_by_chrisccou?= =?utf-8?q?lson?= Message-ID: <20120704141953.30847.73537@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "MozillaTeam/Bugs" page has been changed by chrisccoulson: http://wiki.ubuntu.com/MozillaTeam/Bugs?action=diff&rev1=82&rev2=83 When reporting a bug, it is often useful to determine whether the problem is specific to Ubuntu builds of Firefox and Thunderbird. In order to determine this, please try to recreate the problem in an official Mozilla build of Firefox or Thunderbird. These can be downloaded from the following locations: - * [[www.mozilla.org/firefox/#desktop|Download Firefox]] + * [[http://www.mozilla.org/firefox/#desktop|Download Firefox]] - * [[www.mozilla.org/thunderbird/|Download Thunderbird]] + * [[http://www.mozilla.org/thunderbird/|Download Thunderbird]] To run these you will need to extract the downloaded tarball. Once you have done this, open a terminal and do the following: From webmaster at ubuntu.com Wed Jul 4 16:16:31 2012 From: webmaster at ubuntu.com (Help Ubuntu) Date: Wed, 04 Jul 2012 16:16:31 -0000 Subject: =?utf-8?q?=5BCommunity_Ubuntu_Documentation=5D_Update_of_=22ReportingBugs?= =?utf-8?q?=22_by_penalvch?= Message-ID: <20120704161631.1216.14299@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=180&rev2=181 Comment: Created == Adding Additional Attachments... == == Adding Apport Debug Information to an Existing Launchpad Bug == If you have already reported a bug directly via Launchpad, but want to add additional debugging information via ''Apport'' to the bug report, you can do this by running the command `apport-collect bug_number` via "Run Application" or terminal window. If you are not the original reporter, please do not apport-collect to a bug report unless specifically asked of you by a developer or triager. Running apport-collect when not asked creates spammy E-Mail traffic for those subscribed, clutters up the bug report with undesired attachments, and hinders the bug getting addressed quickly. Instead, please open a new report via ubuntu-bug. + + == Adding Additional Attachments to an Existing Launchpad Bug == + + If you have reported a bug to Launchpad, and want to provide attachments in addition to that collected by ''Apport'', please ensure you do not use external posting sites (ex. pastebin) or post external hyperlinks. Instead, please post the information directly in a comment or as an attachment. If you are not the original reporter, and the problem is in the [[https://launchpad.net/ubuntu/+source/linux|linux]] package, please do not post any attachments to the report. Instead, please report a new bug via ubuntu-bug. <> == Filing a translation bug == From noreply at ubuntu.com Sun Jul 8 11:20:30 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 08 Jul 2012 11:20:30 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingPrintingProblems=22_by_?= =?utf-8?q?till-kamppeter?= Message-ID: <20120708112030.28299.20071@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingPrintingProblems" page has been changed by till-kamppeter: http://wiki.ubuntu.com/DebuggingPrintingProblems?action=diff&rev1=70&rev2=71 To restore the default configuration file /etc/cups/cupsd.conf, run the commands: <
> {{{$ sudo mv /etc/cups/cupsd.conf ~}}} <
> {{{$ apt-get download cups}}} <
> {{{$ sudo dpkg -i --force-confmiss cups_*.deb}}} <
> You can also restore other configuration files, as printers.conf for example. Simply do the same steps but instead of cupsd.conf move away the offending configuration file. + = Turboprint = + + [[http://www.turboprint.info/|Turboprint]] is a comercially distributed manufacturer-independent printer driver package. It is for photo inkjet printers, supporting several models which are not or not well supported by the drivers which come with Ubuntu (Gutenprint, HPLIP) or from the manufacturers and also adds color management with calibration service to all supported printers. You have to pay for the software and for the calibration service. You can download the software for free but after a 30-day trial period a Turboprint logo gets printed on every page. + + We cannot fix bugs in Turboprint, as it is a third-party closed-source software package, like many manufacturer-supplied drivers, but the developers of Turboprint are responsive, so we can forward bug reports to them. + + One known problem is that Turboprint currently ships with a Ghostscript clone based on a very old Ghostscript version, after which we have worked a lot with the original developers of Ghostscript to remove very many crash bugs. So if you have problems that certain (especially more complex) files do not print (and perhaps you find segmentation fault messages of "gszedo" in /var/log/syslog), proceed as follows: + + Run the command <
> {{{$ turboprint}}} <
> A window, "Turbo Print Control Center" will open. Click "Preferences" at the bottom of the window. In the dialog popping up now uncheck "use Ghostscript with extensions for TurboPrint". Click "OK" in the dialog window and "Exit" in the main window. + + This makes Turboprint using the current version of Ghostscript as shipped with Ubuntu, containing all the latest bug fixes. + = Known bugs = Description of known issues, how to recognise them and stock responses/actions. From sd44sd44 at yeah.net Mon Jul 9 15:24:47 2012 From: sd44sd44 at yeah.net (sd44) Date: Mon, 09 Jul 2012 23:24:47 +0800 Subject: Ubuntu 12.10 amd64, assistant(package : qt4-dev-tools 4.8.2-0ubuntu2) Segmentation fault (core dumped) Message-ID: <4FFAF7BF.1070800@yeah.net> Everytime, when it's core dumped, need to rm ~/.local/share/data/Trolltech/Assistant/qthelpcollection_4.8.2.qhc ，then it running。。。。。 From noreply at ubuntu.com Tue Jul 10 15:24:25 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 10 Jul 2012 15:24:25 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Responses=22_by_trekcaptain?= =?utf-8?q?usa-tw?= Message-ID: <20120710152425.28106.86981@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Responses" page has been changed by trekcaptainusa-tw: http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=353&rev2=354 Comment: Added ubuntuforums.org to the list of "A Support request" support sites Determining whether a bug report is actually a support request can be quite challenging, but if you decide the bug is a support request you can convert it to such by clicking "Convert to a question" at the top of the bug's web page. This will mark the bug as "Invalid", create a new question in the answer tracker and link it to the bug. In the comment dialog that you receive, post a comment to inform the reporter about your action, and advise them to use the support tracker for any future problems. - || Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find a valid help posting your problem in the support forum of your local Ubuntu's community http://loco.ubuntu.com/ or asking at http://askubuntu.com. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.|| + || Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find a valid help posting your problem in the support forum of your local Ubuntu's community http://loco.ubuntu.com/ or asking at http://askubuntu.com or asking at http://ubuntuforums.org. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.|| It is also a good idea to change the source package beforehand if it's set incorrectly, so that the question will be associated with the correct package in the answer tracker, or edit the question afterwards and assign it to the correct package. If it doesn't pertain to a specific package, change it to "Ubuntu". From noreply at ubuntu.com Tue Jul 10 16:28:12 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 10 Jul 2012 16:28:12 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Responses=22_by_brian-murra?= =?utf-8?q?y?= Message-ID: <20120710162812.6953.56855@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Responses" page has been changed by brian-murray: http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=354&rev2=355 Comment: Updated bzr branch information <> - These standard responses among with other amazing scripts are also available as a Firefox extension in a PPA at: + These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at: [[https://launchpad.net/~gm-dev-launchpad/+archive/ppa|https://launchpad.net/~gm-dev-launchpad/+archive/ppa]] When you update one of these responses, you should also update the response used by the Firefox extension. - These responses can be found in the bazaar branch [[https://code.launchpad.net/ubuntu-qa-tools|lp:ubuntu-qa-tools]] in the file [[http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/gm-xml-files/bugsquad-replies.xml|gm-xml-files/bugsquad-replies.xml]]. + These responses can be found in the bazaar branch [[https://code.launchpad.net/ubuntu-bugcontrol-tools|lp:ubuntu-bugcontrol-tools]] in the file [[http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-bugcontrol-tools/master/view/head:/gm-xml-files/bugsquad-replies.xml|gm-xml-files/bugsquad-replies.xml]]. To check out a branch, use {{{ - bzr branch lp:ubuntu-qa-tools + bzr branch lp:ubuntu-bugcontrol-tools }}} Only members of bug-control can commit to this branch, but you can submit a merge proposal and Brian Murray will review/merge it (see [[https://lists.ubuntu.com/archives/ubuntu-bugsquad/2010-November/002833.html|this email message]]). From noreply at ubuntu.com Wed Jul 11 09:57:32 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 11 Jul 2012 09:57:32 -0000 Subject: =?utf-8?q?New_attachment_added_to_page_DebuggingProgramCrash_on_Ubuntu_Wi?= =?utf-8?q?ki?= Message-ID: <20120711095732.1536.47498@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page "DebuggingProgramCrash" for change notification. An attachment has been added to that page by pitti. Following detailed information is available: Attachment name: apport-examine-locally.png Attachment size: 23776 Attachment link: http://wiki.ubuntu.com/DebuggingProgramCrash?action=AttachFile&do=get&target=apport-examine-locally.png Page link: http://wiki.ubuntu.com/DebuggingProgramCrash From noreply at ubuntu.com Wed Jul 11 09:57:54 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 11 Jul 2012 09:57:54 -0000 Subject: =?utf-8?q?New_attachment_added_to_page_DebuggingProgramCrash_on_Ubuntu_Wi?= =?utf-8?q?ki?= Message-ID: <20120711095754.1630.34108@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page "DebuggingProgramCrash" for change notification. An attachment has been added to that page by pitti. Following detailed information is available: Attachment name: apport-retrace-gui.png Attachment size: 21695 Attachment link: http://wiki.ubuntu.com/DebuggingProgramCrash?action=AttachFile&do=get&target=apport-retrace-gui.png Page link: http://wiki.ubuntu.com/DebuggingProgramCrash From noreply at ubuntu.com Wed Jul 11 09:58:03 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 11 Jul 2012 09:58:03 -0000 Subject: =?utf-8?q?New_attachment_added_to_page_DebuggingProgramCrash_on_Ubuntu_Wi?= =?utf-8?q?ki?= Message-ID: <20120711095803.1584.27833@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page "DebuggingProgramCrash" for change notification. An attachment has been added to that page by pitti. Following detailed information is available: Attachment name: apport-retrace-gdb.png Attachment size: 43632 Attachment link: http://wiki.ubuntu.com/DebuggingProgramCrash?action=AttachFile&do=get&target=apport-retrace-gdb.png Page link: http://wiki.ubuntu.com/DebuggingProgramCrash From noreply at ubuntu.com Wed Jul 11 10:05:56 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 11 Jul 2012 10:05:56 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingProgramCrash=22_by_pitt?= =?utf-8?q?i?= Message-ID: <20120711100556.7107.80649@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingProgramCrash" page has been changed by pitti: http://wiki.ubuntu.com/DebuggingProgramCrash?action=diff&rev1=112&rev2=113 Comment: document apport-retrace <> ||<>|| - This document describes how to install debug packages on Ubuntu, which will aid in providing information for bugs. + This document describes how to debug Ubuntu package crashes and install debug packages on Ubuntu, which will aid in providing information for bugs. + + == Using apport-retrace == + + If you want to debug a crash in packaged Ubuntu software, [[https://wiki.ubuntu.com/Apport|Apport]] will usually pick it up, create a `.crash` report in `/var/crash/` and report the crashed program. From there it is easiest to use [[http://manpages.ubuntu.com/apport-retrace|apport-retrace]]. + + `apport-retrace` regenerates the stack traces (both the simple and the threaded one) from an apport crash report from the included core dump, or gives you a Terminal window with gdb in an environment with debugging symbols, reproducing the situation of the crash through the core dump. For this it figures out the set of necessary packages and their accompanying debug symbol packages, so that the regenerated stack trace will be fully symbolic and thus become much more useful for developers to fix the problem. + + `apport-retrace` has two modes: By default it will just regenerate traces based on the packages which are currently installed in the system, i. e. it assumes that all necessary debug symbols for the report are installed (see the next paragraph for this). When specifying the `-S` option, it creates a temporary "sandbox" and downloads and installs all necessary packages and debug symbols there. It will not do any changes to your system and does not require any special privileges. + + Please see the [[http://manpages.ubuntu.com/apport-retrace|apport-retrace manpage]] for details and some examples how to run it. + + You can also invoke this directly from the Apport crash notification, by clicking the "Examine locally" button: + + {{attachment:apport-examine-locally.png}} + + This will collect some package information and then ask you in which mode you want to run `apport-retrace`: + + {{attachment:apport-retrace-gui.png}} + + Normally you want to keep the first option, which will get you in a gdb session + in the sandbox: + + {{attachment:apport-retrace-gdb.png}} + + If you do not want an interactive gdb session but just want it to update the already existing `.crash` file with fully symbolic stack traces, you can select the third option. == Debug Symbol Packages == + If you want to debug a crash in a project you are developing yourself or from a third-party package, or need the debug symbols for particular libraries very often, it is helpful to install those permanently into your system. First, check if there is a package with a -dbg suffix in the main Ubuntu repositories. These are the debug symbol packages, and are equivalent to '-dbgsym' described below. You can safely use either one, but not both at once. Try installing the package, adding -dbg to its name, for example: {{{ From noreply at ubuntu.com Wed Jul 11 10:33:48 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 11 Jul 2012 10:33:48 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Chromium/Debugging=22_by_mitya57?= Message-ID: <20120711103348.12580.68661@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Chromium/Debugging" page has been changed by mitya57: http://wiki.ubuntu.com/Chromium/Debugging?action=diff&rev1=11&rev2=12 Comment: Added Debugging page header + <> + ## page was renamed from Chromium/Debug If Chromium crashes and you want to file a bug upstream, use their [[http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux|linux template]]. Always include the output from the following command: From trekcaptainusa.tw at gmail.com Thu Jul 12 19:52:02 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Thu, 12 Jul 2012 15:52:02 -0400 Subject: Core vs. Non-Core definitions In-Reply-To: References: Message-ID: I'm dredging this back up again, given a discussion with hggdh in #ubuntu-bugs. This should *really* be defined, core vs. non core for Importance setting, among other things. Core vs. Non-Core can make a bug either Low or Medium (see bold items, and here: https://wiki.ubuntu.com/Bugs/Importance): •*Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are: * ◦Bugs that have easy work-arounds ◦Bugs that affect unusual end-user configurations or uncommon hardware ◦Bugs that affect a non-essential aspect and limited scope of the application *◦Bugs that have a moderate impact on a non-core application* ◦Cosmetic/usability issues that does not limit the functionality of a non-core application ◦Non-ideal default configurations •*Medium: Most bugs are of medium importance, examples are: * *◦A bug that has a moderate impact on a core application.* ◦A bug that has a severe impact on a non-core application. ◦A bug which impacts accessibility of a non-core application. ◦A usability issue that does not limit the functionality of a core application. ◦A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.) hggdh and I both agree we need to address this and define items. So once again, I'll dredge this topic up so we can define what is or is not core, and then list that accordingly on the bugsquad docs. ---------- Forwarded message ---------- From: Thomas Ward Date: Tue, May 15, 2012 at 9:21 PM Subject: Core vs. Non-Core definitions To: ubuntu-bugsquad at lists.ubuntu.com Hiya, all. This came up (during UDS) in a discussion I had with micahg on IRC, and came up again today in #ubuntu-bugs with roadmr. (NOTE: These are the users' IRC nicks, I do not have their names readily available) The definition of a bug's importance includes the difference between core and non-core on this page here: https://wiki.ubuntu.com/Bugs/Importance There is currently no clear definition of what core or non-core means. At every time I have run into a bug that needs its importance set, I've avoided identifying whether a bug is related to a core or non-core program (except for Universe and Multiverse package bugs), simply because there is no clear-cut definition of what is or is not core. This lack of a definition can sometimes make a recommendation for "medium" actually end up as "low", and vice versa, based on core-vs-noncore. This makes determining importance that much more difficult. Since this is a critical part of determining a bug's importance, we need to, in my opinion, do one of the following:: (a) clearly define what applications specifically are or are not core, and update with each release, or (b) define what constitutes a core or non-core application/program, or (c) rewrite the criterion (and therefore the guide) to remove the difference of core vs. non-core and redefine the bug importance criterion accordingly. micahg was in agreement with me that this needs to be defined, so I thought I would bring this onto the mailing list for discussion and potentially a final decision be made on this. So, thoughts? Opinions? ------ Thomas LP: trekcaptainusa-tw BugSquad Member Ubuntu Member -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Thu Jul 12 22:19:37 2012 From: brian at ubuntu.com (Brian Murray) Date: Thu, 12 Jul 2012 15:19:37 -0700 Subject: Core vs. Non-Core definitions In-Reply-To: References: Message-ID: <20120712221937.GP13466@murraytwins.com> On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote: > I'm dredging this back up again, given a discussion with hggdh in > #ubuntu-bugs. > > This should *really* be defined, core vs. non core for Importance setting, > among other things. > > Core vs. Non-Core can make a bug either Low or Medium (see bold items, and > here: https://wiki.ubuntu.com/Bugs/Importance): I'd say packages that are a part of a task should be considered core and most other things non-core. As an example: apt-cache show empathy | grep ^Task Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb I would consider empathy as a core application. Does that help? -- Brian Murray Ubuntu Bug Master -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From trekcaptainusa.tw at gmail.com Thu Jul 12 22:58:12 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Thu, 12 Jul 2012 18:58:12 -0400 Subject: Core vs. Non-Core definitions In-Reply-To: <20120712221937.GP13466@murraytwins.com> References: <20120712221937.GP13466@murraytwins.com> Message-ID: Apparently GMail fails, so i'm going to include part of the email chain i had with Brian just now that didnt get sent to the mailing list: On Thu, Jul 12, 2012 at 06:37:37PM -0400, Thomas Ward wrote: > Do we include the packages that are part of, say, kubuntu-desktop or > xubuntu-desktop as core as well? Or are we solely focusing on items which > are included in ubuntu and edubuntu releases? On Thu, Jul 12, 2012 at 6:53 PM, Brian Murray wrote: > As kubuntu, mythbuntu, lubuntu et al track their bugs in Launchpad as a > part of the Ubuntu distribution they should all be included. On Thu, Jul 12, 2012 at 6:19 PM, Brian Murray wrote: > On Thu, Jul 12, 2012 at 03:52:02PM -0400, Thomas Ward wrote: > > I'm dredging this back up again, given a discussion with hggdh in > > #ubuntu-bugs. > > > > This should *really* be defined, core vs. non core for Importance > setting, > > among other things. > > > > Core vs. Non-Core can make a bug either Low or Medium (see bold items, > and > > here: https://wiki.ubuntu.com/Bugs/Importance): > > I'd say packages that are a part of a task should be considered core and > most other things non-core. As an example: > > apt-cache show empathy | grep ^Task > Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb > > I would consider empathy as a core application. > > Does that help? > > -- > Brian Murray > Ubuntu Bug Master > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trekcaptainusa.tw at gmail.com Fri Jul 13 14:45:05 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Fri, 13 Jul 2012 10:45:05 -0400 Subject: "Bugs 101" IRC Classroom Sessions Discussion Message-ID: Greetings, fellow bug squad and bug control members! I was talking to pleia2 (on IRC) during the user days geared towards newbies on the classroom, and we happened to start discussing the possibility of members of the bugsquad and/or bugcontrol having sessions relating to bugs, such as how to file them, how the bug lifecycle works, etc. I see a ton of users of other support resources such as Ask Ubuntu or Ubuntu Forums or some of the IRC channels reporting bugs in those methods but not filing bugs, or sometimes filing bugs that aren't even bugs, or arent bound to any package, or the likes. I think it'd be pretty decent if we can get some sessions together to help teach the people who are not as experienced with bugs how to correctly file a bug and how to understand the lifecycle of a bug, and what we do as BugSquad and BugControl members. One of the methods we can teach this by is dedicated classroom sessions on IRC for such things (sort of a Bugs 101) I know Micah thinks this'd be a good idea, so I'm curious who on the bugsquad and bugcontrol would care to participate in such an event, if we decide to add Bugs sessions to the next User Days classroom sessions, or even if we schedule something outside of user days, and what types of topics (including but not limited to a "Bugs 101" session) we should touch upon during such a session. Thoughts? (This is just a discussion right now, if we think this is a good idea we can arrange session times with whomever has control over the classroom calendar) ------ Thomas Ward LPID: trekcaptainusa-tw Ubuntu BugSquad Member CC: ubuntu-bugcontrol mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Thu Jul 12 21:46:04 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Thu, 12 Jul 2012 21:46:04 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Responses=22_by_trekcaptain?= =?utf-8?q?usa-tw?= Message-ID: <20120712214604.3272.84187@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Responses" page has been changed by trekcaptainusa-tw: http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=356&rev2=357 Comment: Updated response for "A support request" at the request of bdmurray, coinciding with code changes in Bug Control Tools. Determining whether a bug report is actually a support request can be quite challenging, but if you decide the bug is a support request you can convert it to such by clicking "Convert to a question" at the top of the bug's web page. This will mark the bug as "Invalid", create a new question in the answer tracker and link it to the bug. In the comment dialog that you receive, post a comment to inform the reporter about your action, and advise them to use the support tracker for any future problems. - || Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find a valid help posting your problem in the support forum of your local Ubuntu's community http://loco.ubuntu.com/ or asking at http://askubuntu.com or asking at http://ubuntuforums.org. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.|| + || Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We understand the difficulties you are facing, but it is better to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. You can also find help with your problem in the support forum of your local Ubuntu community http://loco.ubuntu.com/ or asking at http://askubuntu.com or http://ubuntuforums.org. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs.|| It is also a good idea to change the source package beforehand if it's set incorrectly, so that the question will be associated with the correct package in the answer tracker, or edit the question afterwards and assign it to the correct package. If it doesn't pertain to a specific package, change it to "Ubuntu". From noreply at ubuntu.com Fri Jul 13 15:27:44 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 13 Jul 2012 15:27:44 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Responses=22_by_trekcaptain?= =?utf-8?q?usa-tw?= Message-ID: <20120713152744.30194.25388@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Responses" page has been changed by trekcaptainusa-tw: http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=357&rev2=358 Comment: Modified "Not in english" response to include a more polite greeting thanking the user for filing a bug and making ubuntu better. (code update in gm-xml-files pending linux internet access) This response is appropriate when a bug is not reported in English or some error messages are not in English. - || Some of this bug report is not in English. Please translate it into English to make it more understandable to triagers. Thanks!|| + || Thank you for taking the time to report this issue and helping to make Ubuntu better. Some of this bug report is not in English. Please translate it into English to make it more understandable to triagers. Thanks!|| == Suspected bad ISO download == From matthew.fischer at canonical.com Fri Jul 13 15:37:23 2012 From: matthew.fischer at canonical.com (Matt Fischer) Date: Fri, 13 Jul 2012 09:37:23 -0600 Subject: "Bugs 101" IRC Classroom Sessions Discussion In-Reply-To: References: Message-ID: <500040B3.5090206@canonical.com> On 07/13/2012 08:45 AM, Thomas Ward wrote: > Greetings, fellow bug squad and bug control members! > I was talking to pleia2 (on IRC) during the user days geared towards > newbies on the classroom, and we happened to start discussing the > possibility of members of the bugsquad and/or bugcontrol having > sessions relating to bugs, such as how to file them, how the bug > lifecycle works, etc. > > I see a ton of users of other support resources such as Ask Ubuntu or > Ubuntu Forums or some of the IRC channels reporting bugs in those > methods but not filing bugs, or sometimes filing bugs that aren't even > bugs, or arent bound to any package, or the likes. I think it'd be > pretty decent if we can get some sessions together to help teach the > people who are not as experienced with bugs how to correctly file a > bug and how to understand the lifecycle of a bug, and what we do as > BugSquad and BugControl members. One of the methods we can teach this > by is dedicated classroom sessions on IRC for such things (sort of a > Bugs 101) > > I know Micah thinks this'd be a good idea, so I'm curious who on the > bugsquad and bugcontrol would care to participate in such an event, if > we decide to add Bugs sessions to the next User Days classroom > sessions, or even if we schedule something outside of user days, and > what types of topics (including but not limited to a "Bugs 101" > session) we should touch upon during such a session. Thoughts? > > (This is just a discussion right now, if we think this is a good idea > we can arrange session times with whomever has control over the > classroom calendar) > > ------ > Thomas Ward > LPID: trekcaptainusa-tw > Ubuntu BugSquad Member > > CC: ubuntu-bugcontrol mailing list. > > I can assist in the session or assist in developing notes/material if someone else can be the main owner. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trekcaptainusa.tw at gmail.com Fri Jul 13 15:56:06 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Fri, 13 Jul 2012 11:56:06 -0400 Subject: "Bugs 101" IRC Classroom Sessions Discussion In-Reply-To: References: Message-ID: Who would consider leading one of these sessions? I probably don't have the time to lead the session, but wouldn't mind helping to get the sessions created and scheduled, and probably help out during the sessions as needed. ---------- Forwarded message ---------- From: nathan nolast Date: Fri, Jul 13, 2012 at 11:43 AM Subject: Re: "Bugs 101" IRC Classroom Sessions Discussion To: Thomas Ward im interested in attending any class on filing bugs offered. On Fri, Jul 13, 2012 at 10:45 AM, Thomas Ward wrote: > Greetings, fellow bug squad and bug control members! > > I was talking to pleia2 (on IRC) during the user days geared towards > newbies on the classroom, and we happened to start discussing the > possibility of members of the bugsquad and/or bugcontrol having sessions > relating to bugs, such as how to file them, how the bug lifecycle works, > etc. > > I see a ton of users of other support resources such as Ask Ubuntu or > Ubuntu Forums or some of the IRC channels reporting bugs in those methods > but not filing bugs, or sometimes filing bugs that aren't even bugs, or > arent bound to any package, or the likes. I think it'd be pretty decent if > we can get some sessions together to help teach the people who are not as > experienced with bugs how to correctly file a bug and how to understand the > lifecycle of a bug, and what we do as BugSquad and BugControl members. One > of the methods we can teach this by is dedicated classroom sessions on IRC > for such things (sort of a Bugs 101) > > I know Micah thinks this'd be a good idea, so I'm curious who on the > bugsquad and bugcontrol would care to participate in such an event, if we > decide to add Bugs sessions to the next User Days classroom sessions, or > even if we schedule something outside of user days, and what types of > topics (including but not limited to a "Bugs 101" session) we should touch > upon during such a session. Thoughts? > > (This is just a discussion right now, if we think this is a good idea we > can arrange session times with whomever has control over the classroom > calendar) > > ------ > Thomas Ward > LPID: trekcaptainusa-tw > Ubuntu BugSquad Member > > CC: ubuntu-bugcontrol mailing list. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- Thank you for your time ~Nathan Heafner nathan1465 at gmail.com 704-268-9040 *Please consider the environment before printing this email. * This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trekcaptainusa.tw at gmail.com Fri Jul 13 16:12:41 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Fri, 13 Jul 2012 12:12:41 -0400 Subject: "Bugs 101" IRC Classroom Sessions Discussion In-Reply-To: References: Message-ID: Checked with Elizabeth Krumbach (pleia2 on IRC), the next user days isnt until january-ish, so either we have a ton of time to discuss and plan this, or we can schedule separate sessions outside of userdays. Just a tidbit of information :) ----- Thomas On Fri, Jul 13, 2012 at 11:56 AM, Thomas Ward wrote: > Who would consider leading one of these sessions? I probably don't have > the time to lead the session, but wouldn't mind helping to get the sessions > created and scheduled, and probably help out during the sessions as needed. > > ---------- Forwarded message ---------- > From: nathan nolast > Date: Fri, Jul 13, 2012 at 11:43 AM > Subject: Re: "Bugs 101" IRC Classroom Sessions Discussion > To: Thomas Ward > > > im interested in attending any class on filing bugs offered. > > On Fri, Jul 13, 2012 at 10:45 AM, Thomas Ward < > trekcaptainusa.tw at gmail.com> wrote: > >> Greetings, fellow bug squad and bug control members! >> >> I was talking to pleia2 (on IRC) during the user days geared towards >> newbies on the classroom, and we happened to start discussing the >> possibility of members of the bugsquad and/or bugcontrol having sessions >> relating to bugs, such as how to file them, how the bug lifecycle works, >> etc. >> >> I see a ton of users of other support resources such as Ask Ubuntu or >> Ubuntu Forums or some of the IRC channels reporting bugs in those methods >> but not filing bugs, or sometimes filing bugs that aren't even bugs, or >> arent bound to any package, or the likes. I think it'd be pretty decent if >> we can get some sessions together to help teach the people who are not as >> experienced with bugs how to correctly file a bug and how to understand the >> lifecycle of a bug, and what we do as BugSquad and BugControl members. One >> of the methods we can teach this by is dedicated classroom sessions on IRC >> for such things (sort of a Bugs 101) >> >> I know Micah thinks this'd be a good idea, so I'm curious who on the >> bugsquad and bugcontrol would care to participate in such an event, if we >> decide to add Bugs sessions to the next User Days classroom sessions, or >> even if we schedule something outside of user days, and what types of >> topics (including but not limited to a "Bugs 101" session) we should touch >> upon during such a session. Thoughts? >> >> (This is just a discussion right now, if we think this is a good idea we >> can arrange session times with whomever has control over the classroom >> calendar) >> >> ------ >> Thomas Ward >> LPID: trekcaptainusa-tw >> Ubuntu BugSquad Member >> >> CC: ubuntu-bugcontrol mailing list. >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > > > -- > Thank you for your time > ~Nathan Heafner > nathan1465 at gmail.com > 704-268-9040 > > *Please consider the environment before printing this email. * > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melchiaros at aol.com Mon Jul 16 11:30:20 2012 From: melchiaros at aol.com (melchiaros) Date: Mon, 16 Jul 2012 13:30:20 +0200 Subject: a bug ready for triaging Message-ID: <1342438220.7125.13.camel@linux-khuy> In common I would not send this as E-Mail. This exeption is caused by the rapidly growing number of users that hit this bug(3 times the number of affected since last wendsday) It is bug https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1021517 which I see ready for status triaged. Unfortunally I could not set this by myself, so could anybody do which is allowed to? A identification is done(as xorg-server crash - not gimp where the most user report this at first). The XOrg.log shows a stacktrace of the problem, which is already isolated and copied to the original description. A reproducing procedure is available. It is reproducible to the users which are affected. Because this bug and it`s duplicates are reported manually(not apport reporting possible) it is to expect that the number of affected persons is higher than the seen 25 ones. Greeting melchiaros From noreply at ubuntu.com Fri Jul 13 15:31:33 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 13 Jul 2012 15:31:33 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Bugs/Responses=22_by_trekcaptain?= =?utf-8?q?usa-tw?= Message-ID: <20120713153133.3244.14715@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Bugs/Responses" page has been changed by trekcaptainusa-tw: http://wiki.ubuntu.com/Bugs/Responses?action=diff&rev1=358&rev2=359 Comment: Updated "Not in english" response to match pending-proposed and current wording of gm-xml-files/bugsquad-replies.xml This response is appropriate when a bug is not reported in English or some error messages are not in English. - || Thank you for taking the time to report this issue and helping to make Ubuntu better. Some of this bug report is not in English. Please translate it into English to make it more understandable to triagers. Thanks!|| + || Thank you for taking the time to report this issue and helping to make Ubuntu better. We noticed that some of the sentences in this bug report are not in English. If they were translated to English they would be more understandable to triagers. Could you please translate them?|| == Suspected bad ISO download == From thinkndev at gmail.com Mon Jul 23 20:45:01 2012 From: thinkndev at gmail.com (John Kim) Date: Mon, 23 Jul 2012 13:45:01 -0700 Subject: Linking a bug to another project? Message-ID: Hi, What does it mean to "link to a related branch?' Does it mean sharing the bug report to another group? I'm part of the papercutters team, and I want to merge my problem to the project team so that they could see for themselves. How can I do this? Thanks. -- John Kim Ubuntu enthusiast l ookjohn.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.fischer at canonical.com Mon Jul 23 22:08:29 2012 From: matthew.fischer at canonical.com (Matt Fischer) Date: Mon, 23 Jul 2012 16:08:29 -0600 Subject: Linking a bug to another project? In-Reply-To: References: Message-ID: <500DCB5D.8050909@canonical.com> On 07/23/2012 02:45 PM, John Kim wrote: > Hi, > > What does it mean to "link to a related branch?' Does it mean sharing > the bug report to another group? > > I'm part of the papercutters team, and I want to merge my problem to > the project team so that they could see for themselves. How can I do > this? > > Thanks. > > -- > John Kim > Ubuntu enthusiast > l ookjohn.com > > > John, Link to a related branch means link the bug to a code branch, usually a branch that might have a fix and has been proposed as one. Are you trying to get one bug be assigned to multiple projects? If so, you want to click on "Also affects project" and add hundred paper cuts. This bug for example, affects 5 different projects including papercuts. If thats not what you meant, then I don't fully understand your question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.fischer at canonical.com Mon Jul 23 22:13:35 2012 From: matthew.fischer at canonical.com (Matt Fischer) Date: Mon, 23 Jul 2012 16:13:35 -0600 Subject: Linking a bug to another project? In-Reply-To: <500DCB5D.8050909@canonical.com> References: <500DCB5D.8050909@canonical.com> Message-ID: <500DCC8F.1070208@canonical.com> On 07/23/2012 04:08 PM, Matt Fischer wrote: > On 07/23/2012 02:45 PM, John Kim wrote: >> Hi, >> >> What does it mean to "link to a related branch?' Does it mean >> sharing the bug report to another group? >> >> I'm part of the papercutters team, and I want to merge my problem to >> the project team so that they could see for themselves. How can I do >> this? >> >> Thanks. >> >> -- >> John Kim >> Ubuntu enthusiast >> l ookjohn.com >> >> >> > > John, > > Link to a related branch means link the bug to a code branch, usually > a branch that might have a fix and has been proposed as one. Are you > trying to get one bug be assigned to multiple projects? If so, you > want to click on "Also affects project" and add hundred paper cuts. > This bug for example, affects 5 different projects including papercuts. > > If thats not what you meant, then I don't fully understand your question. > > Sorry, I forgot to paste my example bug: https://bugs.launchpad.net/hundredpapercuts/+bug/625357 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thinkndev at gmail.com Mon Jul 23 22:33:26 2012 From: thinkndev at gmail.com (John Kim) Date: Mon, 23 Jul 2012 15:33:26 -0700 Subject: Linking a bug to another project? In-Reply-To: <500DCB5D.8050909@canonical.com> References: <500DCB5D.8050909@canonical.com> Message-ID: Sorry I wasn't specific enough, but you answered it precisely. Thanks! John K. Ubuntu enthusiast www.lookjohn.com On Jul 23, 2012 3:09 PM, "Matt Fischer" wrote: > On 07/23/2012 02:45 PM, John Kim wrote: > > Hi, > > What does it mean to "link to a related branch?' Does it mean sharing > the bug report to another group? > > I'm part of the papercutters team, and I want to merge my problem to the > project team so that they could see for themselves. How can I do this? > > Thanks. > > -- > John Kim > Ubuntu enthusiast > l ookjohn.com > > > > > John, > > Link to a related branch means link the bug to a code branch, usually a > branch that might have a fix and has been proposed as one. Are you trying > to get one bug be assigned to multiple projects? If so, you want to click > on "Also affects project" and add hundred paper cuts. This bug for > example, affects 5 different projects including papercuts. > > If thats not what you meant, then I don't fully understand your question. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Mon Jul 23 17:15:09 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Mon, 23 Jul 2012 17:15:09 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22LibreOfficeBugWrangling=22_by_pe?= =?utf-8?q?nalvch?= Message-ID: <20120723171509.9670.59970@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "LibreOfficeBugWrangling" page has been changed by penalvch: http://wiki.ubuntu.com/LibreOfficeBugWrangling?action=diff&rev1=13&rev2=14 Comment: Added === Troubleshooting Techniques === === The Whole System Hangs or Boots to the Login Screen === * For instances when you are using LibreOffice and either the system hangs requiring a hard reset or you are booted to the login screen, this is a bug in either xorg or the kernel. Please follow https://help.ubuntu.com/community/DebuggingSystemCrash . As well, if this happened while a particular document was open or you were manipulating the document, please attach that document to the bug report with detailed, click-for-click steps on how to reproduce the crash. + === Troubleshooting Techniques === + Try moving .libreoffice and ~/.config/libreoffice. If you installed any extensions, remove them and see if the problem is reproducible. Comment on the results of performing these techniques in your report. + == Regressions == * For regressions, it is helpful to perform a binary bisect ("bibisect") to narrow down which commit specifically caused the problem. For instructions please see http://sweetshark.livejournal.com/7683.html . From webmaster at ubuntu.com Wed Jul 25 16:03:13 2012 From: webmaster at ubuntu.com (Help Ubuntu) Date: Wed, 25 Jul 2012 16:03:13 -0000 Subject: =?utf-8?q?=5BCommunity_Ubuntu_Documentation=5D_Update_of_=22ReportingBugs?= =?utf-8?q?=22_by_penalvch?= Message-ID: <20120725160313.4919.43604@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=182&rev2=183 Comment: Added = Bug Reporting Etiquette = as many in the community would benefit by being familiar with these bug tracker colloquialisms. <> + ||<>|| + + = Bug Reporting Etiquette = + + Thank you for reading this article. This will guide you on how best to present your bug report so that it gets addressed as soon as possible. Here are a few guiding principles that lead to success in getting bugs fixed: + + * Please do not stack multiple issues into one report. For example, many jam suspend and hibernate into one report. Please do not do this. Make one report for each against the Linux package via a terminal: {{{ubuntu-bug linux}}} + * Please do not complain about how long it takes to fix a bug, the severity of your bug is high so it should be fixed immediately, "I cannot believe it's not fixed...", XYZ person(s) do not care about fixing bugs, etc. Especially, if you have not followed the directions mentioned in this article, let alone contributed code upstream. This type of behavior is unconstructive, irritating to others who read your E-Mail, and spammy. We all want to see every bug fixed as soon as possible! Naturally, bugs being fixed is limited to reproducibility and clarity of the bug report, the actual impact the bug has on the community, and available developer resources. + * Please keep the bug objective as possible. It is desired for you to provide a fact based, technical impact statement on you, your environment, and the potential or actual impact on the community at large. + * Please provide all relevant information from [[https://wiki.ubuntu.com/DebuggingProcedures]] when you first report your bug. This is the number one reason why bugs do not get marked [[https://wiki.ubuntu.com/Bugs/Status|Triaged]], as the minimum requirements for dealing with the problem by a developer are not provided. + * If a triager or developer asks you to provide information, please avoid arguing with them. Just provide the information as requested. If you have a strong disagreement with what a triager or developer is asking of you, please resolve it with them via personal message, instead of turning a bug development report into a "let's talk about talking about the problem" report. The Ubuntu community takes a favor to objective, technical discourse. + * Many of the triagers and developers who are providing support to you, are volunteers doing so out of altruism. Please keep this in mind when making your comments. + * The high majority of [[https://launchpad.net/ubuntu/+source/linux|linux]] package, hardware, non-user space bugs are hardware dependent on both the hardware itself, and what it is connected to. For more on this please see below sections: + [[https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported]] + + [[https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug]] + = How to report bugs = - - ||<>|| Ubuntu uses Launchpad to keep track of bugs and their fixes. This page will guide you through the steps required to file a good and detailed report. @@ -43, +58 @@ If the problem is not in the package [[https://launchpad.net/ubuntu/+source/linux|linux]], and you have further information about an already reported bug, add this information to the existing report, rather than opening a new one. - /!\ '''For sound, X drivers, and kernel bugs''': please open a '''new''' bug instead of commenting on a similar bug: chances are that your hardware does not match the existing bug's hardware, so the bug will not be addressed. As well, unless asked of you by a developer or experienced triager, please do not mark your bug a duplicate of another reporter's bug. + /!\ '''For sound, X drivers, and [[https://launchpad.net/ubuntu/+source/linux|linux]] kernel bugs''': please open a '''new''' bug instead of adding debugging information, attachments, or "Me too!" comments on what may appear to be a similar bug: chances are that your hardware does not match the existing bug's hardware, so your bug and comments will not be addressed. As well, unless asked of you by a developer or triager, please do not mark your bug a duplicate of another reporter's bug. [[#Top|Back to top]] From noreply at ubuntu.com Wed Jul 25 17:11:34 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 25 Jul 2012 17:11:34 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingScreenLocking=22_by_mde?= =?utf-8?q?slaur?= Message-ID: <20120725171134.9973.20453@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingScreenLocking" page has been changed by mdeslaur: http://wiki.ubuntu.com/DebuggingScreenLocking?action=diff&rev1=16&rev2=17 == gnome-screensaver cannot grab keyboard or mouse == - gnome-screensaver will not activate if an applications grabs keyboard and mouse focus. + gnome-screensaver will not activate if an application grabs keyboard and mouse focus. This happens most noticeably with GTK context menus. If a context or panel menu is open, it grabs the pointer and gnome-screensaver never activates. It is also an issue for applications such as VNC, virt-manager, VirtualBox, Remote Desktop Viewer, Terminal Server Client, gnome-keyring, password dialogs, etc. @@ -133, +133 @@ || [[https://bugzilla.gnome.org/show_bug.cgi?id=353437]] || try harder to break grabs || || [[https://bugzilla.gnome.org/show_bug.cgi?id=440515]] || Does not activate screensaver if menu is open || + == Screen is shown, and then screensaver activates again == + + This is a known issue, stemming from the fact that gnome-screensaver will not activate if an application grabs keyboard and mouse focus. + + What happens is the following: + 1- Random application (such as vnc window, or gtk menu) grabs keyboard or mouse + 2- Screensaver attemps to come up after timeout to lock screen, but cannot gain keyboard or mouse lock + 3- Screen gets blanked from DPMS + 4- User moves mouse, turning screen back on with DPMS, and sees desktop + 5- Mouse movement has released keyboard or mouse lock + 6- Screensaver can now grab keyboard and mouse, and locks the screen + + This happens after inactivity, or when suspending a laptop while a problematic application is open. + + There is no current solution for this problem. The screensaver needs to grab the keyboard and the mouse so keystrokes typed in the screensaver login box doesn't get sent to the underlying application. + + The only solution for this problem is for X to gain a way of breaking locks on keyboard and mouse events. + == gnome-screensaver under XFCE (xubuntu, mythbuntu) == Under a XFCE desktop (including xubuntu and mythbuntu), gnome-screensaver never activates after the idle timeout expires. From eldmannen at gmail.com Thu Jul 26 16:39:46 2012 From: eldmannen at gmail.com (Fred .) Date: Thu, 26 Jul 2012 18:39:46 +0200 Subject: ProcMaps.txt may contain private information such as username Message-ID: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1029189 The ProcMaps.txt file that gets uploaded to Launchpad may contain private information such as username that can be obtained from the path of the home directory. 7fbd44c33000-7fbd44c34000 r--s 00000000 08:01 1306557 /home/alice/.local/share/mime/mime.cache I propose scrubbing/anonymizing the username. From trekcaptainusa.tw at gmail.com Fri Jul 27 15:28:52 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Fri, 27 Jul 2012 11:28:52 -0400 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: Message-ID: To quote Andrea Corbellini on the bug you linked us to: > Bug reports created by Apport may containing a variety of sensible > information -- from user names to credit card numbers. If you think that > ProcMaps.txt is leaking private information, than don't look at the other > files! > Well, jokes apart, all potentially sensible information uploaded is always > secured and reviewed by experienced and competent people. When real > sensible information are found, they are removed before a bug report is > made public. There are well-established procedures used to deal with such > cases. These competent people are a small subgroup of people who can see bugs. These bugs are screened for private information such as user names or credit card numbers. Before those bugs get set as publicly visible, members of the teams who can see those private bugs screen the information for such private data, and either remove the file or handle it accordingly. Thus far, I've not witnessed any breaches in this. There have been crash bugs on other applications and packages (of which I have personally triaged or reviewed, as a member of that package's upstream team or as a member of BugControl), and sometimes this "private information" is included in crash stack traces for python programs. Since for the package I referred to only BugControl can see the private information, what I did in that particular instance was obfuscate that information by replacing the user name with 'IAmATeapot' or some other random name that does not exist, thereby obfuscating the information (and of course removing the original file uploaded by Apport), long before setting the bug as a public security bug. If I may ask, Fred, why, personally, would you want that information purged, other than "Oh, my user name is in there"? Generally speaking, if your username is there, but you dont have, say, an SSH server running, or a DMZ'd system with no firewall protection or other form of protection, or are intentionally not hardening your system, disclosing your username is not **too** much of a threat. ------- Thomas Ward LPID: trekcaptainusa-tw Ubuntu BugSquad Member On Thu, Jul 26, 2012 at 12:39 PM, Fred . wrote: > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1029189 > > The ProcMaps.txt file that gets uploaded to Launchpad may contain > private information such as username that can be obtained from the > path of the home directory. > > 7fbd44c33000-7fbd44c34000 r--s 00000000 08:01 1306557 > /home/alice/.local/share/mime/mime.cache > > I propose scrubbing/anonymizing the username. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldmannen at gmail.com Fri Jul 27 15:56:10 2012 From: eldmannen at gmail.com (Fred .) Date: Fri, 27 Jul 2012 17:56:10 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: Message-ID: In a non-automated process such as the manual screening it is easy that by human a slip would occur where such data were not removed. Disclosing the username is not much of a threat, but it was not apparent to the user reporting the bug that hes username would be announced. The username may also be used in social engineering attacks. Also a user might not want his username, realname, or pseudonym identified or associated with his Launchpad account. The user have a expectation that he reports a bug, not sending personal identifiable information. This may trigger spyware allegations. Imagine if Microsoft did this, "Microsoft's bug report software includes spyware that secretly collects personal identifiable information!" and there would be a huge backlash. If Apport detects any personally identifiable information, it should scrub it before sending it to Launchpad. A prerequisite for being a good Ubuntu user who reports bugs is that it is trusted to not collect any personally identifiable information. Many users disable bug reporting for these reasons. As well does many companies as a company-wide policy. Please automatically replace all occurrences of $USER and $HOSTNAME with a dummy string prior to sending the data to Launchpad. On Fri, Jul 27, 2012 at 5:28 PM, Thomas Ward wrote: > To quote Andrea Corbellini on the bug you linked us to: > >> >> Bug reports created by Apport may containing a variety of sensible >> information -- from user names to credit card numbers. If you think that >> ProcMaps.txt is leaking private information, than don't look at the other >> files! > > >> >> Well, jokes apart, all potentially sensible information uploaded is always >> secured and reviewed by experienced and competent people. When real sensible >> information are found, they are removed before a bug report is made public. >> There are well-established procedures used to deal with such cases. > > > These competent people are a small subgroup of people who can see bugs. > These bugs are screened for private information such as user names or credit > card numbers. Before those bugs get set as publicly visible, members of the > teams who can see those private bugs screen the information for such private > data, and either remove the file or handle it accordingly. Thus far, I've > not witnessed any breaches in this. > > There have been crash bugs on other applications and packages (of which I > have personally triaged or reviewed, as a member of that package's upstream > team or as a member of BugControl), and sometimes this "private information" > is included in crash stack traces for python programs. Since for the > package I referred to only BugControl can see the private information, what > I did in that particular instance was obfuscate that information by > replacing the user name with 'IAmATeapot' or some other random name that > does not exist, thereby obfuscating the information (and of course removing > the original file uploaded by Apport), long before setting the bug as a > public security bug. > > > If I may ask, Fred, why, personally, would you want that information purged, > other than "Oh, my user name is in there"? Generally speaking, if your > username is there, but you dont have, say, an SSH server running, or a DMZ'd > system with no firewall protection or other form of protection, or are > intentionally not hardening your system, disclosing your username is not > **too** much of a threat. > > > ------- > Thomas Ward > LPID: trekcaptainusa-tw > Ubuntu BugSquad Member > > On Thu, Jul 26, 2012 at 12:39 PM, Fred . wrote: >> >> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1029189 >> >> The ProcMaps.txt file that gets uploaded to Launchpad may contain >> private information such as username that can be obtained from the >> path of the home directory. >> >> 7fbd44c33000-7fbd44c34000 r--s 00000000 08:01 1306557 >> /home/alice/.local/share/mime/mime.cache >> >> I propose scrubbing/anonymizing the username. >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > From corbellini.andrea at gmail.com Fri Jul 27 17:09:50 2012 From: corbellini.andrea at gmail.com (Andrea Corbellini) Date: Fri, 27 Jul 2012 19:09:50 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: Message-ID: <5012CB5E.2030607@gmail.com> Hi Fred, On 27/07/12 17:56, Fred . wrote: > [...] > Disclosing the username is not much of a threat, but it was not > apparent to the user reporting the bug that hes username would be > announced. Apport actually gives you chances to check the information you submit. Also, for some special packages, you will be explicitly asked to attach some optional files. For example, if you try to file a bug against compiz you will be asked this question: Your display manager log files may help developers diagnose the bug, but may contain sensitive information such as your hostname. Do you want to include these logs in your bug report? > [...] > The user have a expectation that he reports a bug, not sending > personal identifiable information. This may trigger spyware > allegations. I do not agree: whenever you file a bug you are forced to publish personal information about you. Just the fact that you have filed a bug against a package means that you have installed and used it. Also, the information that is attached to bug reports is not meant to spy you, but to help triagers and developers debug and fix the issue. In many cases a simple list of steps to reproduce the bug isn't enough to reproduce it. > Imagine if Microsoft did this, "Microsoft's bug report software > includes spyware that secretly collects personal identifiable > information!" and there would be a huge backlash. Every bug reporting tool must collect some information about what happened and in which circumstances. A report containing just the phrase "application does not work" cannot help anybody fixing the issue. > If Apport detects any personally identifiable information, it should > scrub it before sending it to Launchpad. The problem here is that 1. it's not that easy to know whether an information is private; and 2. sometimes the key of the issue is contained in such private information. Again, think for example of compiz: many times knowing which graphics card is mounted on your computer is *essential* to debug the issue. > A prerequisite for being a good Ubuntu user who reports bugs is that > it is trusted to not collect any personally identifiable information. > Many users disable bug reporting for these reasons. As well does many > companies as a company-wide policy. This is something we know and accept. However, one complete bug report is much much better that thousands vague reports. Nobody forces you to report bugs; if it is not obvious, then it means that the wording of apport & co. is not clear enough. > Please automatically replace all occurrences of $USER and $HOSTNAME > with a dummy string prior to sending the data to Launchpad. The username and the hostname are just two small examples of private information. There are many other information that might be uploaded; detecting and replacing them is not that easy and sometimes it is not even possible. In short: the information collected by Apport is essential (to be honest, sometimes it is not enough). If it's not clear that your bug reports may contain sensible information, than Apport should be improved to tell you that. If it's not clear how to review and remove sensible information from bug reports, than the UI of Launchpad should be improved to make it more obvious. I hope to have resolved all your concerns. By the way, thanks: suggestions and feedback -- in any form -- are always appreciated. From trekcaptainusa.tw at gmail.com Fri Jul 27 17:27:58 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Fri, 27 Jul 2012 13:27:58 -0400 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: (For the record, "PII" means personally identifiable information, whether computer-identifiable or otherwise) As Andrea said, there is *tons* of other PII in reports, and having that information can sometimes make a more complete bug report. It is part of the duties of those who analyze the private bugs which contain PII to identify and remove such things before making a report public. There's no way to remove every individual piece of PII automatically, there's too many variations of what it would look like. This is why people who understand what *is* PII go through these reports. Argue what you want, but I think you're beating a dead horse at this point. It's not likely this'll be implemented, in my opinion (nor do I support automatic removal). On Fri, Jul 27, 2012 at 1:18 PM, Fred . wrote: > Okay, but I still argue for at least automatically replace all > occurrences of $USER and $HOSTNAME with a dummy string prior to > sending the data to Launchpad. > > On Fri, Jul 27, 2012 at 7:09 PM, Andrea Corbellini > wrote: > > Hi Fred, > > > > On 27/07/12 17:56, Fred . wrote: > >> > >> [...] > >> Disclosing the username is not much of a threat, but it was not > >> apparent to the user reporting the bug that hes username would be > >> announced. > > > > > > Apport actually gives you chances to check the information you submit. > Also, > > for some special packages, you will be explicitly asked to attach some > > optional files. For example, if you try to file a bug against compiz you > > will be asked this question: > > > > Your display manager log files may help developers diagnose the bug, > > but may contain sensitive information such as your hostname. Do you > > want to include these logs in your bug report? > > > >> [...] > >> The user have a expectation that he reports a bug, not sending > >> personal identifiable information. This may trigger spyware > >> allegations. > > > > > > I do not agree: whenever you file a bug you are forced to publish > personal > > information about you. Just the fact that you have filed a bug against a > > package means that you have installed and used it. > > > > Also, the information that is attached to bug reports is not meant to spy > > you, but to help triagers and developers debug and fix the issue. In many > > cases a simple list of steps to reproduce the bug isn't enough to > reproduce > > it. > > > >> Imagine if Microsoft did this, "Microsoft's bug report software > >> includes spyware that secretly collects personal identifiable > >> information!" and there would be a huge backlash. > > > > > > Every bug reporting tool must collect some information about what > happened > > and in which circumstances. A report containing just the phrase > "application > > does not work" cannot help anybody fixing the issue. > > > >> If Apport detects any personally identifiable information, it should > >> scrub it before sending it to Launchpad. > > > > > > The problem here is that 1. it's not that easy to know whether an > > information is private; and 2. sometimes the key of the issue is > contained > > in such private information. > > > > Again, think for example of compiz: many times knowing which graphics > card > > is mounted on your computer is *essential* to debug the issue. > > > >> A prerequisite for being a good Ubuntu user who reports bugs is that > >> it is trusted to not collect any personally identifiable information. > >> Many users disable bug reporting for these reasons. As well does many > >> companies as a company-wide policy. > > > > > > This is something we know and accept. However, one complete bug report is > > much much better that thousands vague reports. Nobody forces you to > report > > bugs; if it is not obvious, then it means that the wording of apport & > co. > > is not clear enough. > > > >> Please automatically replace all occurrences of $USER and $HOSTNAME > >> with a dummy string prior to sending the data to Launchpad. > > > > > > The username and the hostname are just two small examples of private > > information. There are many other information that might be uploaded; > > detecting and replacing them is not that easy and sometimes it is not > even > > possible. > > > > > > In short: the information collected by Apport is essential (to be honest, > > sometimes it is not enough). > > If it's not clear that your bug reports may contain sensible information, > > than Apport should be improved to tell you that. > > If it's not clear how to review and remove sensible information from bug > > reports, than the UI of Launchpad should be improved to make it more > > obvious. > > > > > > I hope to have resolved all your concerns. By the way, thanks: > suggestions > > and feedback -- in any form -- are always appreciated. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Fri Jul 27 16:44:40 2012 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Fri, 27 Jul 2012 16:44:40 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingKernelSuspendHibernateR?= =?utf-8?q?esume=22_by_anthonywong?= Message-ID: <20120727164440.14356.18147@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingKernelSuspendHibernateResume" page has been changed by anthonywong: http://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume?action=diff&rev1=21&rev2=22 Thank you for taking the time to report this bug and helping to make Ubuntu better. This report seems to indicate that your battery drained while the machine was suspended. In this case a false bug report is generated, we are therefore closing this bug Invalid. Please see https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume for more information. = See also = - * [[SuspendResumeTesting]] + * [[KernelTeam/SuspendResumeTesting]] ---- CategoryKernel CategoryDebugging From eldmannen at gmail.com Fri Jul 27 17:18:16 2012 From: eldmannen at gmail.com (Fred .) Date: Fri, 27 Jul 2012 19:18:16 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: <5012CB5E.2030607@gmail.com> References: <5012CB5E.2030607@gmail.com> Message-ID: Okay, but I still argue for at least automatically replace all occurrences of $USER and $HOSTNAME with a dummy string prior to sending the data to Launchpad. On Fri, Jul 27, 2012 at 7:09 PM, Andrea Corbellini wrote: > Hi Fred, > > On 27/07/12 17:56, Fred . wrote: >> >> [...] >> Disclosing the username is not much of a threat, but it was not >> apparent to the user reporting the bug that hes username would be >> announced. > > > Apport actually gives you chances to check the information you submit. Also, > for some special packages, you will be explicitly asked to attach some > optional files. For example, if you try to file a bug against compiz you > will be asked this question: > > Your display manager log files may help developers diagnose the bug, > but may contain sensitive information such as your hostname. Do you > want to include these logs in your bug report? > >> [...] >> The user have a expectation that he reports a bug, not sending >> personal identifiable information. This may trigger spyware >> allegations. > > > I do not agree: whenever you file a bug you are forced to publish personal > information about you. Just the fact that you have filed a bug against a > package means that you have installed and used it. > > Also, the information that is attached to bug reports is not meant to spy > you, but to help triagers and developers debug and fix the issue. In many > cases a simple list of steps to reproduce the bug isn't enough to reproduce > it. > >> Imagine if Microsoft did this, "Microsoft's bug report software >> includes spyware that secretly collects personal identifiable >> information!" and there would be a huge backlash. > > > Every bug reporting tool must collect some information about what happened > and in which circumstances. A report containing just the phrase "application > does not work" cannot help anybody fixing the issue. > >> If Apport detects any personally identifiable information, it should >> scrub it before sending it to Launchpad. > > > The problem here is that 1. it's not that easy to know whether an > information is private; and 2. sometimes the key of the issue is contained > in such private information. > > Again, think for example of compiz: many times knowing which graphics card > is mounted on your computer is *essential* to debug the issue. > >> A prerequisite for being a good Ubuntu user who reports bugs is that >> it is trusted to not collect any personally identifiable information. >> Many users disable bug reporting for these reasons. As well does many >> companies as a company-wide policy. > > > This is something we know and accept. However, one complete bug report is > much much better that thousands vague reports. Nobody forces you to report > bugs; if it is not obvious, then it means that the wording of apport & co. > is not clear enough. > >> Please automatically replace all occurrences of $USER and $HOSTNAME >> with a dummy string prior to sending the data to Launchpad. > > > The username and the hostname are just two small examples of private > information. There are many other information that might be uploaded; > detecting and replacing them is not that easy and sometimes it is not even > possible. > > > In short: the information collected by Apport is essential (to be honest, > sometimes it is not enough). > If it's not clear that your bug reports may contain sensible information, > than Apport should be improved to tell you that. > If it's not clear how to review and remove sensible information from bug > reports, than the UI of Launchpad should be improved to make it more > obvious. > > > I hope to have resolved all your concerns. By the way, thanks: suggestions > and feedback -- in any form -- are always appreciated. From eldmannen at gmail.com Fri Jul 27 18:02:26 2012 From: eldmannen at gmail.com (Fred .) Date: Fri, 27 Jul 2012 20:02:26 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: Yes, things like hardware information is useful for a complete bug report. But I doubt username and hostname would be necessary for a complete report. Not all potential PII can, should or ought to be removed. But I do think that the $USER and $HOSTNAME should definitely without a doubt be scrubbed. Why should $USER and $HOSTNAME not be automatically scrubbed? On Fri, Jul 27, 2012 at 7:27 PM, Thomas Ward wrote: > (For the record, "PII" means personally identifiable information, whether > computer-identifiable or otherwise) > > As Andrea said, there is *tons* of other PII in reports, and having that > information can sometimes make a more complete bug report. It is part of > the duties of those who analyze the private bugs which contain PII to > identify and remove such things before making a report public. > > There's no way to remove every individual piece of PII automatically, > there's too many variations of what it would look like. This is why people > who understand what *is* PII go through these reports. > > Argue what you want, but I think you're beating a dead horse at this point. > It's not likely this'll be implemented, in my opinion (nor do I support > automatic removal). > > > > > On Fri, Jul 27, 2012 at 1:18 PM, Fred . wrote: >> >> Okay, but I still argue for at least automatically replace all >> occurrences of $USER and $HOSTNAME with a dummy string prior to >> sending the data to Launchpad. >> >> On Fri, Jul 27, 2012 at 7:09 PM, Andrea Corbellini >> wrote: >> > Hi Fred, >> > >> > On 27/07/12 17:56, Fred . wrote: >> >> >> >> [...] >> >> Disclosing the username is not much of a threat, but it was not >> >> apparent to the user reporting the bug that hes username would be >> >> announced. >> > >> > >> > Apport actually gives you chances to check the information you submit. >> > Also, >> > for some special packages, you will be explicitly asked to attach some >> > optional files. For example, if you try to file a bug against compiz you >> > will be asked this question: >> > >> > Your display manager log files may help developers diagnose the bug, >> > but may contain sensitive information such as your hostname. Do you >> > want to include these logs in your bug report? >> > >> >> [...] >> >> The user have a expectation that he reports a bug, not sending >> >> personal identifiable information. This may trigger spyware >> >> allegations. >> > >> > >> > I do not agree: whenever you file a bug you are forced to publish >> > personal >> > information about you. Just the fact that you have filed a bug against a >> > package means that you have installed and used it. >> > >> > Also, the information that is attached to bug reports is not meant to >> > spy >> > you, but to help triagers and developers debug and fix the issue. In >> > many >> > cases a simple list of steps to reproduce the bug isn't enough to >> > reproduce >> > it. >> > >> >> Imagine if Microsoft did this, "Microsoft's bug report software >> >> includes spyware that secretly collects personal identifiable >> >> information!" and there would be a huge backlash. >> > >> > >> > Every bug reporting tool must collect some information about what >> > happened >> > and in which circumstances. A report containing just the phrase >> > "application >> > does not work" cannot help anybody fixing the issue. >> > >> >> If Apport detects any personally identifiable information, it should >> >> scrub it before sending it to Launchpad. >> > >> > >> > The problem here is that 1. it's not that easy to know whether an >> > information is private; and 2. sometimes the key of the issue is >> > contained >> > in such private information. >> > >> > Again, think for example of compiz: many times knowing which graphics >> > card >> > is mounted on your computer is *essential* to debug the issue. >> > >> >> A prerequisite for being a good Ubuntu user who reports bugs is that >> >> it is trusted to not collect any personally identifiable information. >> >> Many users disable bug reporting for these reasons. As well does many >> >> companies as a company-wide policy. >> > >> > >> > This is something we know and accept. However, one complete bug report >> > is >> > much much better that thousands vague reports. Nobody forces you to >> > report >> > bugs; if it is not obvious, then it means that the wording of apport & >> > co. >> > is not clear enough. >> > >> >> Please automatically replace all occurrences of $USER and $HOSTNAME >> >> with a dummy string prior to sending the data to Launchpad. >> > >> > >> > The username and the hostname are just two small examples of private >> > information. There are many other information that might be uploaded; >> > detecting and replacing them is not that easy and sometimes it is not >> > even >> > possible. >> > >> > >> > In short: the information collected by Apport is essential (to be >> > honest, >> > sometimes it is not enough). >> > If it's not clear that your bug reports may contain sensible >> > information, >> > than Apport should be improved to tell you that. >> > If it's not clear how to review and remove sensible information from bug >> > reports, than the UI of Launchpad should be improved to make it more >> > obvious. >> > >> > >> > I hope to have resolved all your concerns. By the way, thanks: >> > suggestions >> > and feedback -- in any form -- are always appreciated. > > From persia at ubuntu.com Fri Jul 27 23:18:16 2012 From: persia at ubuntu.com (Emmet Hikory) Date: Sat, 28 Jul 2012 08:18:16 +0900 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: <20120727231816.GB26655@gerdhr.shipstone> Fred . wrote: > Yes, things like hardware information is useful for a complete bug report. > But I doubt username and hostname would be necessary for a complete report. With this I must disagree. I have triaged at least two bugs where the bug was specifically related to specific characters or sequences of characters present in either the user's username or associated GECOS information. Admittedly, these strings were visible in the stacktrace or traceback (one of the specific bugs I remember was a C program and the other python) as well as from ancillary sources (such as ProcMaps.txt), but the fact that they were sourced from the /etc/passwd file on the user machine was plainly obvious. While I can't disagree that the information disclosed, may, for some user configurations, disclose more information than the user may have desired, or even meet the definitions of some requires-consent-for-disclosure requirements in some jurisdictions, this information may be essential to an understanding and repair of the bug, depending on the bug. As long as we make best efforts to prevent this information being made completely public, and restrict it to those the project trusts to care for the software in question, I think we've done the right thing. As soon as we start auto-munging data, we have a real possibility of generating a false bug report: one where the bug is real and exists and is trivial to replicate, yet cannot be replicated from the data provided, and so likely cannot be understood by a triager or developer. Note that this does require some discretion on the part of bug reporters: we may be able to do better in terms of informing bug reporters precisely what information is being disclosed, and helping them to understand the submitted report: while there isn't that much space in the Apport dialogues, adding a link to some wiki page with more detailed user-oriented documentation on how to determine what information is being disclosed may help to reduce the chance that reporters are unhappy with the submitted information, or may increase the chance that when a bug does depend on private information, the user will replicate it in a safe environment, so that the submitted information does not provide a compromise. As an example of the last one, there is a "bug" related to the interaction of gnome-screensaver and IMEs, such that if a user has a username or password that contains characters requiring an IME to enter, the user cannot unlock their screen. I haven't retested this against lightdm yet, but gdm allowed users with this information to log in, causing some confusion for folk whose keyboard definitions didn't have native representations for the characters concerned (for example, assume that one includes Cyrillic in one's password: users who have multilayer keyboard maps can unlock the screensaver, but users who use an IME to generate Cyrillic cannot). For reports of this bug we needed to know an affected username and password pair in order to identify the issue, and it was submitted from an otherwise fresh install with intentionally useless information, as obfuscation removes the ability to replicate. (triage note: because screen-savers may hide secure information, it is considered unsafe to allow arbitrary hooks to run arbitrary installed software, so that this example "bug" cannot be fixed: all users are advised to limit their usernames and passwords to strings that do not require an IME). As a hypothetical example, imagine an application that needs to process credit cards (perhaps a library used as part of a framework for a web shop) which crashes on a server. Imagine that the crash occurred because of the introduction of a new allowable string length for credit card numbers (the current rules allow 10, 11, or 12 digits, with a few different grouping models). In such a case, we may need to have a credit card number that causes the crash in order to replicate the bug. Obviously, it would be irresponsible of the server administrators to submit the credit card of one of their customers to our bug tracker. Similarly, it would be irresponsible of us to make such a number public did they do so. I would hope that such a hypothetical situation would be resolved by the administrators replicating the bug on a test or development server using a checksum-consistent credit card number not matching any known real number, and submitting the bug with the false information: with the current system, they could so note their procedure in a comment, so we would know it was safe to disclose the invalid number, so that the developers could extend the software to support the new format. With a system that automatically obfuscates data, we would have no means to determine how to replicate the bug, thereby allowing it to spread unfixed to other services as they adopt Ubuntu and as their customers receive cards with the new format, perhaps causing Ubuntu to receive a poor reputation for online commerce. As with this extreme example, there are potential cases where nearly any datapoint is essential to the solution of the problem. And in all cases, only the reporter can know whether information that appears personally identifying or personally sensitive is accurate (rather than deliberately constructed on a test system to replicate a bug). As such, we must rely on the reporter for appropriate discretion on what is submitted, and maintain a reputation that allows reporters to rely on us for appropriate discretion on what is made public. -- Emmet HIKORY From gomyhr at gmail.com Sun Jul 29 18:31:49 2012 From: gomyhr at gmail.com (Geir Ove Myhr) Date: Sun, 29 Jul 2012 20:31:49 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: On Fri, Jul 27, 2012 at 8:02 PM, Fred . wrote: > Not all potential PII can, should or ought to be removed. But I do > think that the $USER and $HOSTNAME should definitely without a doubt > be scrubbed. > > Why should $USER and $HOSTNAME not be automatically scrubbed? Any automatic scrubbing of pre-defined strings can have funny consequences, as this example shows: http://yro.slashdot.org/story/12/06/01/186216/war-and-nookd-ebook-regex-gone-haywire I will imagine my submitted logs would look funny if such a feature existed, since I usually use short usernames on my systems, such as "go" (my initials). One way to make it easier for people who are worried about the logs leaking information that they consider private (but most other don't), would be to have an option to set a bug report to private initially. Then the submitter can look through and remove/edit files that they do not want to make public. Geir Ove From eldmannen at gmail.com Mon Jul 30 02:21:03 2012 From: eldmannen at gmail.com (Fred .) Date: Mon, 30 Jul 2012 04:21:03 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: Then someone with a basic knowledge of regular expressions should write the regex. I don't think a regex would cause us any problems. /^\/home\/(\w+)\/ On Sun, Jul 29, 2012 at 8:31 PM, Geir Ove Myhr wrote: > On Fri, Jul 27, 2012 at 8:02 PM, Fred . wrote: >> Not all potential PII can, should or ought to be removed. But I do >> think that the $USER and $HOSTNAME should definitely without a doubt >> be scrubbed. >> >> Why should $USER and $HOSTNAME not be automatically scrubbed? > > Any automatic scrubbing of pre-defined strings can have funny > consequences, as this example shows: > http://yro.slashdot.org/story/12/06/01/186216/war-and-nookd-ebook-regex-gone-haywire > > I will imagine my submitted logs would look funny if such a feature > existed, since I usually use short usernames on my systems, such as > "go" (my initials). > > One way to make it easier for people who are worried about the logs > leaking information that they consider private (but most other don't), > would be to have an option to set a bug report to private initially. > Then the submitter can look through and remove/edit files that they do > not want to make public. > > Geir Ove From flyingstar16 at gmail.com Mon Jul 30 13:29:35 2012 From: flyingstar16 at gmail.com (Claudio Moretti) Date: Mon, 30 Jul 2012 15:29:35 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: On Mon, Jul 30, 2012 at 4:21 AM, Fred . wrote: > Then someone with a basic knowledge of regular expressions should > write the regex. I don't think a regex would cause us any problems. > > /^\/home\/(\w+)\/ > That does not solve the problem about replacing usernames such as "go".. The regex would replace the word even in places where it's not supposed to be removed (A stacktrace with the "go" word in it?). Even though I don't think this privacy issue is this big, what about allowing the user to temporarily replace his/hers username and hostname with pre-defined variables? Apport might replace $USER and $HOSTNAME temporarily, if the user wants to. (I'm not really sure this is entirely possible, but I was thinking about launching apport as $: USER= HOSTNAME= apport or exporting the two variables and then resetting it to the correct ones.. I don't really know, though, because it might cause trouble in name resolution because of /etc/hosts ) Cheers, Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldmannen at gmail.com Mon Jul 30 13:50:28 2012 From: eldmannen at gmail.com (Fred .) Date: Mon, 30 Jul 2012 15:50:28 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: You wouldn't search and replace for just "go", you would include the directory separator and search for "/go/", and probably even include home there and search for "/home/go/" So a stacktrace should be no problem. Yeah, temporarily replacing $USER and $HOSTNAME or exporting the variables could be a solution too. On Mon, Jul 30, 2012 at 3:29 PM, Claudio Moretti wrote: > On Mon, Jul 30, 2012 at 4:21 AM, Fred . wrote: >> >> Then someone with a basic knowledge of regular expressions should >> write the regex. I don't think a regex would cause us any problems. >> >> /^\/home\/(\w+)\/ > > > That does not solve the problem about replacing usernames such as "go".. The > regex would replace the word even in places where it's not supposed to be > removed (A stacktrace with the "go" word in it?). > > Even though I don't think this privacy issue is this big, what about > allowing the user to temporarily replace his/hers username and hostname with > pre-defined variables? Apport might replace $USER and $HOSTNAME temporarily, > if the user wants to. (I'm not really sure this is entirely possible, but I > was thinking about launching apport as > $: USER= HOSTNAME= apport > > or exporting the two variables and then resetting it to the correct ones.. I > don't really know, though, because it might cause trouble in name resolution > because of /etc/hosts > ) > > Cheers, > Claudio From webmaster at ubuntu.com Mon Jul 30 14:56:33 2012 From: webmaster at ubuntu.com (Help Ubuntu) Date: Mon, 30 Jul 2012 14:56:33 -0000 Subject: =?utf-8?q?=5BCommunity_Ubuntu_Documentation=5D_Update_of_=22ReportingBugs?= =?utf-8?q?=22_by_penalvch?= Message-ID: <20120730145633.14904.99247@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=186&rev2=187 Comment: Added details on improving bug reports throughout the article * Please provide all relevant information from [[https://wiki.ubuntu.com/DebuggingProcedures]] when you first report your bug. This is the number one reason why bugs do not get marked [[https://wiki.ubuntu.com/Bugs/Status|Triaged]], as the minimum requirements for dealing with the problem by a developer are not provided. * If a triager or developer asks you to provide information, please avoid arguing with them. Just provide the information as requested. If you have a strong disagreement with what a triager or developer is asking of you, please resolve it with them via personal message, instead of turning a bug development report into a "let's talk about talking about the problem" report. The Ubuntu community takes a favor to objective, technical discourse. * Many of the triagers and developers who are providing support to you, are volunteers doing so out of altruism. Please keep this in mind when making your comments. - * The high majority of [[https://launchpad.net/ubuntu/+source/linux|linux]] package, hardware, non-user space bugs are hardware dependent on both the hardware itself, and what it is connected to. The general rule of thumb is one report, per person, per hardware combination, per bug. For more on this please see below sections: + * The high majority of [[https://launchpad.net/ubuntu/+source/linux|linux]] package, hardware, non-user space bugs are hardware dependent on both the hardware itself, and what it is connected to. The rule of thumb is one report, per person, per hardware combination, per bug. For more on this please see below sections: [[https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported]] [[https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug]] @@ -59, +59 @@ * [[http://www.ubuntu.com/getubuntu/releasenotes/1204|Ubuntu 12.04 LTS (Precise Pangolin)]] If the problem is not in the package [[https://launchpad.net/ubuntu/+source/linux|linux]], and you have further information about an already reported bug, add this information to the existing report, rather than opening a new one. + If the problem is in the package [[https://launchpad.net/ubuntu/+source/linux|linux]], and you are the original reporter, here are the ways to maximize the speed with which your bug is fixed: + * Check for the problem in the earliest release that works for your hardware and the lastest. Report your testing results in the report. + * If your bug is a regression, commit bisect it following https://wiki.ubuntu.com/Kernel/KernelBisection . Report your bisect results in the report. + * Test for this problem in the mainline kernel following https://wiki.ubuntu.com/Kernel/MainlineBuilds . Report your mainline testing results in the report. + * Please do not assume because you have the same desktop or laptop model line as another original reporter's bug report, that your problem is the same. Frequently, computer vendors use different parts under the hood within the same model line. + === Sound, X drivers, Linux Kernel Bugs === + - /!\ '''For sound, X drivers, and [[https://launchpad.net/ubuntu/+source/linux|linux]] kernel bugs''': please open a '''new''' bug instead of adding debugging information, attachments, or "Me too!" comments on what may appear to be a similar bug: chances are that your hardware does not match the existing bug's hardware, so your bug and comments will not be addressed. As well, unless asked of you by a developer or triager, please do not mark your bug a duplicate of another reporter's bug. + /!\ '''For sound, X drivers, and [[https://launchpad.net/ubuntu/+source/linux|linux]] kernel bugs''': please open a '''new''' report instead of adding debugging information, attachments, apport-collect'ing, or "Me too!" comments on what may appear to be a similar bug: chances are that your hardware does not match the existing bug's hardware, so your bug and comments will not be addressed. As well, unless asked of you by a developer or triager, please do not mark your bug a duplicate of another reporter's bug. [[#Top|Back to top]] From flyingstar16 at gmail.com Mon Jul 30 16:01:21 2012 From: flyingstar16 at gmail.com (Claudio Moretti) Date: Mon, 30 Jul 2012 18:01:21 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: > You wouldn't search and replace for just "go", you would include the > directory separator and search for "/go/", and probably even include > home there and search for "/home/go/" > So a stacktrace should be no problem. > Sure, but you won't be able to replace strings that contain only the username, and the user at hostname:pwd string too.. Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldmannen at gmail.com Mon Jul 30 16:40:07 2012 From: eldmannen at gmail.com (Fred .) Date: Mon, 30 Jul 2012 18:40:07 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: Well then just modifying $USER and $HOSTNAME maybe work? What options do we have for improving privacy and prevent PII leakage? On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti wrote: > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: >> >> You wouldn't search and replace for just "go", you would include the >> directory separator and search for "/go/", and probably even include >> home there and search for "/home/go/" >> So a stacktrace should be no problem. > > > Sure, but you won't be able to replace strings that contain only the > username, and the user at hostname:pwd string too.. > > Claudio From trekcaptainusa.tw at gmail.com Mon Jul 30 17:45:33 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Mon, 30 Jul 2012 13:45:33 -0400 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: You mean from humans going through with a fine toothed comb, and having more than one user look at it? I work in IT Security, i can identify PII relatively easily. Part of my job is to identify instances of PII leakage, whether accidental or maliciously. I can spot those things. Likely, most of Bug Control can identify that as well. As I've said and at least one other person has said on this email chain, I think the likelihood of PII leakage falls upon two groups of people: the competency of people on the team(s) that can see the private bugs, and the competency of the user who is submitting the data to actually *look* at what's being submitted. I believe apport should better identify the risk of submitting the information, making a note that PII might be in the report. I still believe that autoremoving these items is not a good idea. Even then, if I thought it *were* a good idea, there's a feasibility issue here, of how to automatically identify and remove the information. How are we going to identify *every variation* of how PII shows up? How're we going to remove that PII without any side-effects (see the 'go' example in the email chain)? I also personally believe that the likelihood of any true PII leakage is at or near zero. Most of the responsibility falls on the users themselves to say "Do I really want to include this information?", and if so then that's the end of it, otherwise they have to go through and decide whether they really want to include the information. (I might be restating my opinions, but from my perspective as someone who works with PII fairly often, and as a programmer, there is a "feature feasibility" issue here) ----------- Thomas On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: > Well then just modifying $USER and $HOSTNAME maybe work? > > What options do we have for improving privacy and prevent PII leakage? > > On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti > wrote: > > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: > >> > >> You wouldn't search and replace for just "go", you would include the > >> directory separator and search for "/go/", and probably even include > >> home there and search for "/home/go/" > >> So a stacktrace should be no problem. > > > > > > Sure, but you won't be able to replace strings that contain only the > > username, and the user at hostname:pwd string too.. > > > > Claudio > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldmannen at gmail.com Mon Jul 30 18:20:16 2012 From: eldmannen at gmail.com (Fred .) Date: Mon, 30 Jul 2012 20:20:16 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <5012CB5E.2030607@gmail.com> Message-ID: Yeah, users can look what is being submitted. On one hand, the user really wants to submit that bug and help out. On the other hand, the user does not want to reveal PII and compromise his privacy. The user is nice enough to take the time to report a bug, he it putting in effort and time. Why should he have to sacrifice his privacy too? What reasonable actions can we take to prevent PII leakage? If we cant get rid of all PII leakage, maybe we can at least reduce it. What measures can we take to increase privacy, decrease PII leakage, while not reducing the quality of the report? Could $USER and $HOSTNAME be assigned something else to the Apport process? On Mon, Jul 30, 2012 at 7:45 PM, Thomas Ward wrote: > You mean from humans going through with a fine toothed comb, and having more > than one user look at it? > > I work in IT Security, i can identify PII relatively easily. Part of my job > is to identify instances of PII leakage, whether accidental or maliciously. > I can spot those things. Likely, most of Bug Control can identify that as > well. > > As I've said and at least one other person has said on this email chain, I > think the likelihood of PII leakage falls upon two groups of people: the > competency of people on the team(s) that can see the private bugs, and the > competency of the user who is submitting the data to actually *look* at > what's being submitted. I believe apport should better identify the risk of > submitting the information, making a note that PII might be in the report. > I still believe that autoremoving these items is not a good idea. > > Even then, if I thought it *were* a good idea, there's a feasibility issue > here, of how to automatically identify and remove the information. How are > we going to identify *every variation* of how PII shows up? How're we going > to remove that PII without any side-effects (see the 'go' example in the > email chain)? > > I also personally believe that the likelihood of any true PII leakage is at > or near zero. Most of the responsibility falls on the users themselves to > say "Do I really want to include this information?", and if so then that's > the end of it, otherwise they have to go through and decide whether they > really want to include the information. > > (I might be restating my opinions, but from my perspective as someone who > works with PII fairly often, and as a programmer, there is a "feature > feasibility" issue here) > > > ----------- > Thomas > > > On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: >> >> Well then just modifying $USER and $HOSTNAME maybe work? >> >> What options do we have for improving privacy and prevent PII leakage? >> >> On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti >> wrote: >> > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: >> >> >> >> You wouldn't search and replace for just "go", you would include the >> >> directory separator and search for "/go/", and probably even include >> >> home there and search for "/home/go/" >> >> So a stacktrace should be no problem. >> > >> > >> > Sure, but you won't be able to replace strings that contain only the >> > username, and the user at hostname:pwd string too.. >> > >> > Claudio >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > From stevec at couttsnet.com Mon Jul 30 20:54:00 2012 From: stevec at couttsnet.com (=?utf-8?B?c3RldmVjQGNvdXR0c25ldC5jb20=?=) Date: Mon, 30 Jul 2012 21:54:00 +0100 Subject: =?utf-8?B?UmU6IFByb2NNYXBzLnR4dCBtYXkgY29udGFpbiBwcml2YXRlIGluZm9ybWF0aW9u?= =?utf-8?B?IHN1Y2ggYXMgdXNlcm5hbWU=?= Message-ID: <20120730205433.AC8545B46D5@smtp.netwizards.co.uk> Far too much effort is being put into this non-issue. Sent from my HTC ----- Reply message ----- From: "Fred ." To: "Thomas Ward" Cc: Subject: ProcMaps.txt may contain private information such as username Date: Mon, Jul 30, 2012 19:20 Yeah, users can look what is being submitted. On one hand, the user really wants to submit that bug and help out. On the other hand, the user does not want to reveal PII and compromise his privacy. The user is nice enough to take the time to report a bug, he it putting in effort and time. Why should he have to sacrifice his privacy too? What reasonable actions can we take to prevent PII leakage? If we cant get rid of all PII leakage, maybe we can at least reduce it. What measures can we take to increase privacy, decrease PII leakage, while not reducing the quality of the report? Could $USER and $HOSTNAME be assigned something else to the Apport process? On Mon, Jul 30, 2012 at 7:45 PM, Thomas Ward wrote: > You mean from humans going through with a fine toothed comb, and having more > than one user look at it? > > I work in IT Security, i can identify PII relatively easily. Part of my job > is to identify instances of PII leakage, whether accidental or maliciously. > I can spot those things. Likely, most of Bug Control can identify that as > well. > > As I've said and at least one other person has said on this email chain, I > think the likelihood of PII leakage falls upon two groups of people: the > competency of people on the team(s) that can see the private bugs, and the > competency of the user who is submitting the data to actually *look* at > what's being submitted. I believe apport should better identify the risk of > submitting the information, making a note that PII might be in the report. > I still believe that autoremoving these items is not a good idea. > > Even then, if I thought it *were* a good idea, there's a feasibility issue > here, of how to automatically identify and remove the information. How are > we going to identify *every variation* of how PII shows up? How're we going > to remove that PII without any side-effects (see the 'go' example in the > email chain)? > > I also personally believe that the likelihood of any true PII leakage is at > or near zero. Most of the responsibility falls on the users themselves to > say "Do I really want to include this information?", and if so then that's > the end of it, otherwise they have to go through and decide whether they > really want to include the information. > > (I might be restating my opinions, but from my perspective as someone who > works with PII fairly often, and as a programmer, there is a "feature > feasibility" issue here) > > > ----------- > Thomas > > > On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: >> >> Well then just modifying $USER and $HOSTNAME maybe work? >> >> What options do we have for improving privacy and prevent PII leakage? >> >> On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti >> wrote: >> > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: >> >> >> >> You wouldn't search and replace for just "go", you would include the >> >> directory separator and search for "/go/", and probably even include >> >> home there and search for "/home/go/" >> >> So a stacktrace should be no problem. >> > >> > >> > Sure, but you won't be able to replace strings that contain only the >> > username, and the user at hostname:pwd string too.. >> > >> > Claudio >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- Ubuntu-bugsquad mailing list Ubuntu-bugsquad at lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad -------------- next part -------------- An HTML attachment was scrubbed... URL: From trekcaptainusa.tw at gmail.com Mon Jul 30 22:09:12 2012 From: trekcaptainusa.tw at gmail.com (Thomas Ward) Date: Mon, 30 Jul 2012 18:09:12 -0400 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <20120730205433.AC8545B46D5@smtp.netwizards.co.uk> Message-ID: *THIS* email chain is a non-issue. Your bug was also marked as a non-issue. We've already established this is an issue where the user needs to be more proactive in bugs. Your concerns are not based in any solid fact, and as I've said before, everyone on the bug control team knows what to look for. Therefore, this *is* a non-issue. Thomas On Mon, Jul 30, 2012 at 5:26 PM, Fred . wrote: > I don't think privacy is a non-issue. > > On Mon, Jul 30, 2012 at 10:54 PM, stevec at couttsnet.com > wrote: > > Far too much effort is being put into this non-issue. > > > > Sent from my HTC > > > > > > ----- Reply message ----- > > From: "Fred ." > > To: "Thomas Ward" > > Cc: > > Subject: ProcMaps.txt may contain private information such as username > > Date: Mon, Jul 30, 2012 19:20 > > > > > > Yeah, users can look what is being submitted. > > On one hand, the user really wants to submit that bug and help out. > > On the other hand, the user does not want to reveal PII and compromise > > his privacy. > > > > The user is nice enough to take the time to report a bug, he it > > putting in effort and time. > > Why should he have to sacrifice his privacy too? > > > > What reasonable actions can we take to prevent PII leakage? > > If we cant get rid of all PII leakage, maybe we can at least reduce it. > > > > What measures can we take to increase privacy, decrease PII leakage, > while > > not > > reducing the quality of the report? > > > > Could $USER and $HOSTNAME be assigned something else to the Apport > process? > > > > On Mon, Jul 30, 2012 at 7:45 PM, Thomas Ward > > wrote: > >> You mean from humans going through with a fine toothed comb, and having > >> more > >> than one user look at it? > >> > >> I work in IT Security, i can identify PII relatively easily. Part of my > >> job > >> is to identify instances of PII leakage, whether accidental or > >> maliciously. > >> I can spot those things. Likely, most of Bug Control can identify that > as > >> well. > >> > >> As I've said and at least one other person has said on this email > chain, I > >> think the likelihood of PII leakage falls upon two groups of people: the > >> competency of people on the team(s) that can see the private bugs, and > the > >> competency of the user who is submitting the data to actually *look* at > >> what's being submitted. I believe apport should better identify the > risk > >> of > >> submitting the information, making a note that PII might be in the > report. > >> I still believe that autoremoving these items is not a good idea. > >> > >> Even then, if I thought it *were* a good idea, there's a feasibility > issue > >> here, of how to automatically identify and remove the information. How > >> are > >> we going to identify *every variation* of how PII shows up? How're we > >> going > >> to remove that PII without any side-effects (see the 'go' example in the > >> email chain)? > >> > >> I also personally believe that the likelihood of any true PII leakage is > >> at > >> or near zero. Most of the responsibility falls on the users themselves > to > >> say "Do I really want to include this information?", and if so then > that's > >> the end of it, otherwise they have to go through and decide whether they > >> really want to include the information. > >> > >> (I might be restating my opinions, but from my perspective as someone > who > >> works with PII fairly often, and as a programmer, there is a "feature > >> feasibility" issue here) > >> > >> > >> ----------- > >> Thomas > >> > >> > >> On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: > >>> > >>> Well then just modifying $USER and $HOSTNAME maybe work? > >>> > >>> What options do we have for improving privacy and prevent PII leakage? > >>> > >>> On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti < > flyingstar16 at gmail.com> > >>> wrote: > >>> > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: > >>> >> > >>> >> You wouldn't search and replace for just "go", you would include the > >>> >> directory separator and search for "/go/", and probably even include > >>> >> home there and search for "/home/go/" > >>> >> So a stacktrace should be no problem. > >>> > > >>> > > >>> > Sure, but you won't be able to replace strings that contain only the > >>> > username, and the user at hostname:pwd string too.. > >>> > > >>> > Claudio > >>> > >>> -- > >>> Ubuntu-bugsquad mailing list > >>> Ubuntu-bugsquad at lists.ubuntu.com > >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > >> > >> > > > > -- > > Ubuntu-bugsquad mailing list > > Ubuntu-bugsquad at lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at ubuntu.com Mon Jul 30 22:25:54 2012 From: brian at ubuntu.com (Brian Murray) Date: Mon, 30 Jul 2012 15:25:54 -0700 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: Message-ID: <20120730222554.GY13466@murraytwins.com> On Thu, Jul 26, 2012 at 06:39:46PM +0200, Fred . wrote: > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1029189 > > The ProcMaps.txt file that gets uploaded to Launchpad may contain > private information such as username that can be obtained from the > path of the home directory. > > 7fbd44c33000-7fbd44c34000 r--s 00000000 08:01 1306557 > /home/alice/.local/share/mime/mime.cache > > I propose scrubbing/anonymizing the username. As we can see in the apport source code[1], apport does try to anonymize information like the username in bug reports and this includes checking ProcMaps.txt. It does not seem to have worked in this particular case and this should be reported as a bug about apport. Please let us know the bug number if you open one. [1] http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/view/head:/apport/report.py#L1294 Thanks! -- Brian Murray Ubuntu Bug Master -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From brian at ubuntu.com Mon Jul 30 22:28:18 2012 From: brian at ubuntu.com (Brian Murray) Date: Mon, 30 Jul 2012 15:28:18 -0700 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: <20120730222554.GY13466@murraytwins.com> References: <20120730222554.GY13466@murraytwins.com> Message-ID: <20120730222818.GZ13466@murraytwins.com> On Mon, Jul 30, 2012 at 03:25:54PM -0700, Brian Murray wrote: > On Thu, Jul 26, 2012 at 06:39:46PM +0200, Fred . wrote: > > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1029189 > > > > The ProcMaps.txt file that gets uploaded to Launchpad may contain > > private information such as username that can be obtained from the > > path of the home directory. > > > > 7fbd44c33000-7fbd44c34000 r--s 00000000 08:01 1306557 > > /home/alice/.local/share/mime/mime.cache > > > > I propose scrubbing/anonymizing the username. > > As we can see in the apport source code[1], apport does try to anonymize > information like the username in bug reports and this includes checking > ProcMaps.txt. It does not seem to have worked in this particular case > and this should be reported as a bug about apport. Please let us know > the bug number if you open one. Oh, I see you did open one. I'll ensure it is in the proper state. -- Brian Murray Ubuntu Bug Master -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From eldmannen at gmail.com Tue Jul 31 00:53:52 2012 From: eldmannen at gmail.com (Fred .) Date: Tue, 31 Jul 2012 02:53:52 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: References: <20120730205433.AC8545B46D5@smtp.netwizards.co.uk> Message-ID: The user must always be respected. It is a shame that we reward those who help with reporting bugs by sacrificing their privacy. Maybe the user doesn't want anyone to have access to that information, and that includes the bug control cabal? I don't think anonymizing $USER and $HOSTNAME is too much to ask. I am sure there have to be ways to implement it in a good way that doesn't compromise the quality/integrity of the report. On Tue, Jul 31, 2012 at 12:09 AM, Thomas Ward wrote: > *THIS* email chain is a non-issue. Your bug was also marked as a non-issue. > We've already established this is an issue where the user needs to be more > proactive in bugs. Your concerns are not based in any solid fact, and as > I've said before, everyone on the bug control team knows what to look for. > Therefore, this *is* a non-issue. > > Thomas > > > On Mon, Jul 30, 2012 at 5:26 PM, Fred . wrote: >> >> I don't think privacy is a non-issue. >> >> On Mon, Jul 30, 2012 at 10:54 PM, stevec at couttsnet.com >> wrote: >> > Far too much effort is being put into this non-issue. >> > >> > Sent from my HTC >> > >> > >> > ----- Reply message ----- >> > From: "Fred ." >> > To: "Thomas Ward" >> > Cc: >> > Subject: ProcMaps.txt may contain private information such as username >> > Date: Mon, Jul 30, 2012 19:20 >> > >> > >> > Yeah, users can look what is being submitted. >> > On one hand, the user really wants to submit that bug and help out. >> > On the other hand, the user does not want to reveal PII and compromise >> > his privacy. >> > >> > The user is nice enough to take the time to report a bug, he it >> > putting in effort and time. >> > Why should he have to sacrifice his privacy too? >> > >> > What reasonable actions can we take to prevent PII leakage? >> > If we cant get rid of all PII leakage, maybe we can at least reduce it. >> > >> > What measures can we take to increase privacy, decrease PII leakage, >> > while >> > not >> > reducing the quality of the report? >> > >> > Could $USER and $HOSTNAME be assigned something else to the Apport >> > process? >> > >> > On Mon, Jul 30, 2012 at 7:45 PM, Thomas Ward >> > wrote: >> >> You mean from humans going through with a fine toothed comb, and having >> >> more >> >> than one user look at it? >> >> >> >> I work in IT Security, i can identify PII relatively easily. Part of >> >> my >> >> job >> >> is to identify instances of PII leakage, whether accidental or >> >> maliciously. >> >> I can spot those things. Likely, most of Bug Control can identify that >> >> as >> >> well. >> >> >> >> As I've said and at least one other person has said on this email >> >> chain, I >> >> think the likelihood of PII leakage falls upon two groups of people: >> >> the >> >> competency of people on the team(s) that can see the private bugs, and >> >> the >> >> competency of the user who is submitting the data to actually *look* at >> >> what's being submitted. I believe apport should better identify the >> >> risk >> >> of >> >> submitting the information, making a note that PII might be in the >> >> report. >> >> I still believe that autoremoving these items is not a good idea. >> >> >> >> Even then, if I thought it *were* a good idea, there's a feasibility >> >> issue >> >> here, of how to automatically identify and remove the information. How >> >> are >> >> we going to identify *every variation* of how PII shows up? How're we >> >> going >> >> to remove that PII without any side-effects (see the 'go' example in >> >> the >> >> email chain)? >> >> >> >> I also personally believe that the likelihood of any true PII leakage >> >> is >> >> at >> >> or near zero. Most of the responsibility falls on the users themselves >> >> to >> >> say "Do I really want to include this information?", and if so then >> >> that's >> >> the end of it, otherwise they have to go through and decide whether >> >> they >> >> really want to include the information. >> >> >> >> (I might be restating my opinions, but from my perspective as someone >> >> who >> >> works with PII fairly often, and as a programmer, there is a "feature >> >> feasibility" issue here) >> >> >> >> >> >> ----------- >> >> Thomas >> >> >> >> >> >> On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: >> >>> >> >>> Well then just modifying $USER and $HOSTNAME maybe work? >> >>> >> >>> What options do we have for improving privacy and prevent PII leakage? >> >>> >> >>> On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti >> >>> >> >>> wrote: >> >>> > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: >> >>> >> >> >>> >> You wouldn't search and replace for just "go", you would include >> >>> >> the >> >>> >> directory separator and search for "/go/", and probably even >> >>> >> include >> >>> >> home there and search for "/home/go/" >> >>> >> So a stacktrace should be no problem. >> >>> > >> >>> > >> >>> > Sure, but you won't be able to replace strings that contain only the >> >>> > username, and the user at hostname:pwd string too.. >> >>> > >> >>> > Claudio >> >>> >> >>> -- >> >>> Ubuntu-bugsquad mailing list >> >>> Ubuntu-bugsquad at lists.ubuntu.com >> >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> >> >> >> > >> > -- >> > Ubuntu-bugsquad mailing list >> > Ubuntu-bugsquad at lists.ubuntu.com >> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > From eldmannen at gmail.com Mon Jul 30 21:26:45 2012 From: eldmannen at gmail.com (Fred .) Date: Mon, 30 Jul 2012 23:26:45 +0200 Subject: ProcMaps.txt may contain private information such as username In-Reply-To: <20120730205433.AC8545B46D5@smtp.netwizards.co.uk> References: <20120730205433.AC8545B46D5@smtp.netwizards.co.uk> Message-ID: I don't think privacy is a non-issue. On Mon, Jul 30, 2012 at 10:54 PM, stevec at couttsnet.com wrote: > Far too much effort is being put into this non-issue. > > Sent from my HTC > > > ----- Reply message ----- > From: "Fred ." > To: "Thomas Ward" > Cc: > Subject: ProcMaps.txt may contain private information such as username > Date: Mon, Jul 30, 2012 19:20 > > > Yeah, users can look what is being submitted. > On one hand, the user really wants to submit that bug and help out. > On the other hand, the user does not want to reveal PII and compromise > his privacy. > > The user is nice enough to take the time to report a bug, he it > putting in effort and time. > Why should he have to sacrifice his privacy too? > > What reasonable actions can we take to prevent PII leakage? > If we cant get rid of all PII leakage, maybe we can at least reduce it. > > What measures can we take to increase privacy, decrease PII leakage, while > not > reducing the quality of the report? > > Could $USER and $HOSTNAME be assigned something else to the Apport process? > > On Mon, Jul 30, 2012 at 7:45 PM, Thomas Ward > wrote: >> You mean from humans going through with a fine toothed comb, and having >> more >> than one user look at it? >> >> I work in IT Security, i can identify PII relatively easily. Part of my >> job >> is to identify instances of PII leakage, whether accidental or >> maliciously. >> I can spot those things. Likely, most of Bug Control can identify that as >> well. >> >> As I've said and at least one other person has said on this email chain, I >> think the likelihood of PII leakage falls upon two groups of people: the >> competency of people on the team(s) that can see the private bugs, and the >> competency of the user who is submitting the data to actually *look* at >> what's being submitted. I believe apport should better identify the risk >> of >> submitting the information, making a note that PII might be in the report. >> I still believe that autoremoving these items is not a good idea. >> >> Even then, if I thought it *were* a good idea, there's a feasibility issue >> here, of how to automatically identify and remove the information. How >> are >> we going to identify *every variation* of how PII shows up? How're we >> going >> to remove that PII without any side-effects (see the 'go' example in the >> email chain)? >> >> I also personally believe that the likelihood of any true PII leakage is >> at >> or near zero. Most of the responsibility falls on the users themselves to >> say "Do I really want to include this information?", and if so then that's >> the end of it, otherwise they have to go through and decide whether they >> really want to include the information. >> >> (I might be restating my opinions, but from my perspective as someone who >> works with PII fairly often, and as a programmer, there is a "feature >> feasibility" issue here) >> >> >> ----------- >> Thomas >> >> >> On Mon, Jul 30, 2012 at 12:40 PM, Fred . wrote: >>> >>> Well then just modifying $USER and $HOSTNAME maybe work? >>> >>> What options do we have for improving privacy and prevent PII leakage? >>> >>> On Mon, Jul 30, 2012 at 6:01 PM, Claudio Moretti >>> wrote: >>> > On Mon, Jul 30, 2012 at 3:50 PM, Fred . wrote: >>> >> >>> >> You wouldn't search and replace for just "go", you would include the >>> >> directory separator and search for "/go/", and probably even include >>> >> home there and search for "/home/go/" >>> >> So a stacktrace should be no problem. >>> > >>> > >>> > Sure, but you won't be able to replace strings that contain only the >>> > username, and the user at hostname:pwd string too.. >>> > >>> > Claudio >>> >>> -- >>> Ubuntu-bugsquad mailing list >>> Ubuntu-bugsquad at lists.ubuntu.com >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad