search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
530 stars 46 forks source link

Semi-automated bug reporting system #4579

Open DemiMarie opened 5 years ago

DemiMarie commented 5 years ago

Qubes OS version:

Qubes release 4.0 (R4.0)

Affected component(s):

qubes-core-admin, I believe.

Steps to reproduce the behavior:

Commands sometimes fail with Got an empty response from qubesd. See journalctl in dom0 for more details.

Expected behavior:

Since these are bugs, Qubes should offer to record various information (such as a backtrace) and send it to a domU (of the user’s choice) so that the user can then attach it to a bug report. If there is a core dump, Qubes should probably save it locally, but not include it in the dump by default.

Actual behavior:

Qubes doesn’t do this.

General notes:

There is a potential for this to collect sensitive data. I believe that this is strongly mitigated, for a few reasons:

  1. This is opt-in. The user must manually choose to send the data to a VM and make the bug report.
  2. In my experiences, backtraces very rarely contain sensitive data beyond qube names. Qube names are not, at least in my experience, likely to be highly sensitive.
  3. While core dumps are likely to contain sensitive data, this proposal does not include them by default. It merely saves them in dom0 for future analysis.

Related issues:

andrewdavidwong commented 5 years ago

In my experiences, backtraces very rarely contain sensitive data beyond qube names. Qube names are not, at least in my experience, likely to be highly sensitive.

The right way to handle this is to let the user decide. Only the user is in a position to decide whether qube names are sensitive or not. We just need to explain the situation in clear, understandable language and leave it up to the user to include that information (or not).

Likewise, we need to be very clear that Qubes has absolutely no ability to transmit any kind of data back to us automatically. There is no automatic bug reporting, no button you can accidentally click that might send of your information to us. It'll literally be a matter of copy/pasting text into one of these GitHub issues, so there's no way you can do it without knowing it.

DemiMarie commented 5 years ago

In my experiences, backtraces very rarely contain sensitive data beyond qube names. Qube names are not, at least in my experience, likely to be highly sensitive.

The right way to handle this is to let the user decide. Only the user is in a position to decide whether qube names are sensitive or not. We just need to explain the situation in clear, understandable language and leave it up to the user to include that information (or not).

Likewise, we need to be very clear that Qubes has absolutely no ability to transmit any kind of data back to us automatically. There is no automatic bug reporting, no button you can accidentally click that might send of your information to us. It'll literally be a matter of copy/pasting text into one of these GitHub issues, so there's no way you can do it without knowing it.

I agree.

unman commented 5 years ago

Depending on the level of customization, (which may not have been done by the end user), qube names can be highly sensitive, and I dont think the mitigation offered is enough. I'm opposed to the stated "expected behaviour". Offer to save in dom0? - perhaps. Offer to save and copy to a (possibly compromised) qube? That seems like a step too far.