How to delete an uploaded crash report?

Hi!

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’ve since run

apt-get purge apport whoopsie

and added

Package: apport whoopsie
Pin: release o=Ubuntu
Pin-Priority: -1

to

/etc/apt/preferences.d/<filename>

to prevent the problem from recurring.

Thank you in advance.

BTW: This seems to have happened to others as well.

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.

You can.

Run the command below, from the machine in question. It will launch a browser, showing only the crash reports from that machine.

xdg-open https://errors.ubuntu.com/user/$(sudo cat /var/lib/whoopsie/whoopsie-id)

This is what you’ll see, but your crash reports, not mine :slight_smile:

3 Likes

They did. It may have been a side effect of various issues I ran into during
the upgrade, though.

Does this stripping occur automatically before the reports hit
errors.ubuntu.com and (some) people can see them?

I will contact someone on this list. Thanks! :slightly_smiling_face:

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:

It doesn’t look like the reports are only accessible to a limited number of Canonical employees?

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.

Good luck!

1 Like

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.

4 Likes

Settings > Privacy & Security is missing in Ubuntu Mate, at least in 24.04.

I did the upgrade from 20.04 to 22.04 to 24.04 with do-release-upgrade and wasn’t asked anything about apport.

Interestingly, /var/lib/apport/autoreport still exists on my system, even after doing apt-get purge apport. I’ll remove it, just in case.

Thanks for the suggestion! How do I make the bug private?

I would:

  1. Open a bug without mentioning your machine ID.
  2. On the newly created bug’s page you can set it to private.
  3. Add your machine ID to the bug report.
3 Likes

About data sent with error reports see: Data privacy | Ubuntu and Canonical Legal | Ubuntu
and

In Ubuntu your whoopsie-id is a long string of chars in /var/lib/whoopsie/whoopsie-id
so you can see it with sudo cat /var/lib/whoopsie/whoopsie-id

Unfortunately, this directory is wiped clean by a cron job that runs every
week, so no luck there. :frowning:

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. :slight_smile:

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.

1 Like

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 */
1 Like

It certainly did for me.

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

3 Likes

Wow! Thanks a lot for your effort. Much appreciated. :slight_smile: Digging through the last backup of my Ubuntu Mate 20.04 installation, it turns out:

  1. It starts life as Ubuntu Mate 19.10 and is upgraded.
  2. The file /var/lib/apport/autoreport exists.
  3. whoopsie is disabled:
# find /etc/ -iname "*whoopsie*"
/etc/dbus-1/system.d/com.ubuntu.WhoopsiePreferences.conf
/etc/init/whoopsie.conf
/etc/init.d/whoopsie
/etc/rc1.d/K01whoopsie
/etc/rc2.d/K01whoopsie
/etc/rc3.d/K01whoopsie
/etc/rc4.d/K01whoopsie
/etc/rc5.d/K01whoopsie
/etc/whoopsie

As a comparison, after reinstalling whoopsie on Ubuntu Mate 24.04, I get:

# find /etc/ -iname "*whoopsie*"
/etc/dbus-1/system.d/com.ubuntu.WhoopsiePreferences.conf
/etc/rc5.d/S01whoopsie
/etc/systemd/system/multi-user.target.wants/whoopsie.path
/etc/rc3.d/S01whoopsie
/etc/rc1.d/K01whoopsie
/etc/rc2.d/S01whoopsie
/etc/init/whoopsie.conf
/etc/rc4.d/S01whoopsie
/etc/init.d/whoopsie

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!

1 Like

Wrong place to look :wink: Ubuntu dropped sysv-init compatibility long ago (around 14.04 … with a full switch to systemd in 16.04)

what you want is:

ogra@acheron:~$ find /lib/systemd/ -iname "*whoopsie*"
/lib/systemd/system/whoopsie.service
/lib/systemd/system/whoopsie.path
ogra@acheron:~$ 
1 Like

Well, my point with:

# find /etc/ -iname "*whoopsie*"
/etc/dbus-1/system.d/com.ubuntu.WhoopsiePreferences.conf
/etc/init/whoopsie.conf
/etc/init.d/whoopsie
/etc/rc1.d/K01whoopsie
/etc/rc2.d/K01whoopsie
/etc/rc3.d/K01whoopsie
/etc/rc4.d/K01whoopsie
/etc/rc5.d/K01whoopsie
/etc/whoopsie

was to show BOTH the state of the /etc/rc<runlevel>.d/NNwhoopsie links AND the missing link in /etc/systemd/:

# find /etc/systemd/ -iname "*whoopsie*" | wc -l
0

Both point to the fact that no whoopsie service is enabled.

More Ubuntu Mate 20.04 context:

# find /lib/systemd/ -iname "*whoopsie*"
/lib/systemd/system/whoopsie.service

# cat /lib/systemd/system/whoopsie.service
[Unit]
Description=crash report submission daemon
After=network-online.target
Wants=network-online.target

[Service]
Environment="CRASH_DB_URL=https://daisy.ubuntu.com"
ExecStart=/usr/bin/whoopsie -f
Restart=always

[Install]
WantedBy=multi-user.target

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.

4 Likes

Thanks for sharing this very useful information with the community.

2 Likes

Hello there,

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 :slight_smile:

3 Likes

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. :slight_smile: