After a recent upgrade from Ubuntu Mate 20.04 to Ubuntu Mate 24.04 (via Ubuntu Mate 22.04), I’ve noticed a number of
Uploading /var/crash/<application>.<uid>.crash
entries in my log, i.e., crash reports have been submitted to errors.ubuntu.com. This has happened without my consent and the reports may contain core dumps with sensitive data. How do I get them deleted? It seems I cannot access even my own submissions on errors.ubuntu.com.
I would be very surprised if they went without consent. I know the dialog changed, in that it is less ‘naggy’ than it used to be. Meaning, it asks once, and if you click the “Don’t ask again” then that is now remembered for future crash reports.
This gets stripped. But yes, there will be data in them, and the reports are only accessible to a limited number of Canonical employees.
I do not know, but I suspect you will need to contact someone on the bug squad, and use the information below to identify “your” crash reports for them to delete.
I’ve tried that already (with my own whoopsie-id) and while it does give me a list of my error reports, when I click one of them I just get the message:
Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access.
This means I can’t figure out how much sensitive data is contained in the error report. Also, the form for requesting access is this one:
I don’t know. The source code is open source, so it’s possible to figure that out, I imagine. But probably easier to ask someone on the team.
That list is incredibly outdated. The page hasn’t been touched for 15 years. Some of those people left Canonical, and so will no longer have access. When I worked there, I lost my access as soon as I left the company.
Well, again, whoopsie is open source, and the exact data submitted is in your /var/crash/*.crash on your machine.
It’s entirely possible there are 3rd parties with access, for sure.
Consent is usually sought in those first login dialogs after installation. But it’s easy to not notice and click through the dialogs. Maybe the dialog is missing in MATE?
To disable automatic crash reports in a regular Ubuntu GNOME session you can go to Settings > Privacy & Security > Diagnostics > Send error reports to Canonical.
I’m not sure all flavours will offer the same level of GUI configuration but it looks like the underlying setting is just a test for whether /var/lib/apport/autoreport exists. So just delete that file if you want to turn off automatic crash reports:
sudo rm /var/lib/apport/autoreport
If you can’t find a way to delete reports that have already been sent (I don’t know of a way) then you should log a private bug with the developers and hopefully they can help.
Unfortunately, this directory is wiped clean by a cron job that runs every
week, so no luck there.
I’ve opened a bug report and will see what happens, but still, if you (or anyone else) know of a more direct line to get the problem resolved, please tell.
Yes, error reports may include core dumps with personal information.
Ubuntu Mate 24.04 does not have the Privacy & Security panel in Settings.
I also wonder how effective machine-scrubbing of arbitrary core dumps can be?
Indeed. Fortunately, I had a backup of this file that I could restore after purging the whoopsie package.
In order to try and replicate @inquisitive-wombat setup, I installed Ubuntu MATE 20.04.6.
By default, /var/lib/apport/autoreport does not exist, apport and whoopsie packages are installed.
I then updated the system with sudo apt update; sudo apt dist-upgrade, and then rebooted.
I ran sudo do-release-upgrade to upgrade from Ubuntu MATE 20.04 LTS to 22.04 LTS.
I then ran sudo do-release-upgrade to upgrade from Ubuntu MATE 22.04 LTS to 24.04 LTS.
The /var/lib/apport/autoreport file still doesn’t exist, and there are no crash reports in /var/crash. So nothing turned that on for me through the standard upgrade process.
In the end I forced an error to occur, which triggered a crash report to be created, and the usual crash dialog to appear. Note that it has the “Remember this in future” option is not ticked by default.
Fun fact, it’ll be the same ID if you re-installed whoopsie. But you don’t have to, because it’s generated (generally) based on a hash of the first ethernet device MAC address, which doesn’t change often.
/* The database identifier. Either:
* - The android serial number, taken from sys, and SHA-512 hashed
* - The system UUID, taken from the DMI tables and SHA-512 hashed
* - The MAC address of the first non-loopback device, SHA-512 hashed */
After the point release update from 24.04.1 to 24.04.2 this never showed and I simply assumed there were no crashes and never thought about until this thread.So I looked into var/lib/apport and autoreportwas present along with crash reports that were automatically uploaded.Once I deleted autoreport the standard crash dialog appeared again when there was a crash and I was given the opportunity to “Send”,“Not Send” and “Remember this in future” .
My guess would be that you switched to the new release before final release …
It is a typical thing that auto-reports are turned on during the development cycle, they usually get turned off shortly before release in the installation defaults for the package, so if you do-release-upgrade to a beta or to some time between beta and final release you might have gotten the development defaults and these will not be switched back (like packages that got installed wrongly due to false dependencies during development or broken settings will not be auto-fixed either in such cases, it is expected that a user that switched to a dev release deals with that on their own)
That would be the only explanation why it could get switched on for you during a release upgrade
Is it plausible that /var/lib/apport/autoreport exists by default in Ubuntu Mate 19.10 and/or that whoopsie went from a (possibly manually) disabled sysvinit service to an enabled systemd service during the upgrade? If you can confirm any of this, I’ll amend my bug report.
Good to know that one is not completely SOL if the file is lost. Thanks!
After a bit of research, I’ve discovered that the “Daisy Pluckers” team (Daisy Pluckers in Launchpad) can remove crash reports. However, you may not want to bother since the core dump (which likely contains the most sensitive data in the crash report, if any) is deleted automatically once the crash report has been processed. Here’s a (slightly redacted) quote from a member of the team:
The amount of crashes we collect means we can’t store [coredumps] indefinitely, and as soon as a crash has burned all its retracing attempts, whether it’s failed or success, the coredump is deleted to save space. And for completeness: the only treatment those coredump are sent to, is that “retracing” mechanism, where we try to load stacktraces in GDB, with added debug symbols. Those cores have thus only been stored in our internal swift storage, and deleted after likely a few hours. That swift storage is only accessible to a few people: [A], [B], and [C], given that we maintain the service, plus the team of SRE in IS that obviously has access to most of the infrastructure, because they host it.
I wasn’t aware of that thread until I was put in the loop to handle the deletion.
To add to that quote, it’s totally fine contacting daisy pluckers for this type of request. Please make sure to include the OOPS IDs you want deleted, you can find them in /var/crash/<crash_name>.uploaded.
The Error Tracker is currently going through a migration + modernization, meaning we can’t really put feature development high in the list of priorities, and that includes improving the documentation. Once that migration is finished, rest assured that we’ll get to better document the whole thing.
And about that “retracing” mechanism, if you’re curious, the code is right there. Feel free to come help clean that up
Looking forward to improved documentation and hopefully some way for users to read and delete their own crash reports, so they can know exactly what they’re sharing with random people on the internet and put a stop to it if so desired.
Ubuntu dropped sysv-init compatibility long ago (around 14.04 … with a full switch to systemd in 16.04)