Pitfalls of the Ubuntu bug tracker - Was: volume past 100% and vol control

[C de-Avillez]

On Thu, 11 Feb 2016 04:04:55 +0100
Ralf Mardorf <silver.bullet at zoho.com> wrote:

> On Wed, 10 Feb 2016 16:57:34 -0600, C de-Avillez wrote:
> >Can we please stop with FUD?  
> 
> So you call me a liar?
> 
> This is what is mentioned by the Ubuntu Wiki and I refer to this
> information, I'm not liar:
> 
>  "Along with the report, Whoopsie sends an obfuscated (SHA512) system
>  identifier (DMI system UUID). This information is collected so that
> we can show a graph of the average errors per calendar day. It also
> lets us answer questions like, “is Ubuntu more stable in the first
> week of use or subsequent weeks?” -
> https://wiki.ubuntu.com/ErrorTracker

??

I do not follow you. So being able to discard duplicates is bad?

And what is the issue with the error tracker?

> 
> /sys/class/dmi/id/product_uuid (dmidecode | grep -i uuid) is
> absolutely not needed, it's unique for Ubuntu to be interested in
> this ID.
> 
>  "Apport collects potentially sensitive data, such as core dumps,
> stack traces, and log files. They can contain passwords, credit card
> numbers, serial numbers, and other private material." -
>  https://wiki.ubuntu.com/Apport
> 
> That's the nature of those files, but it's much more of a risk if a
> user does use an automated tool instead of doing it manually.

Really does not scale. This is how we used to do it before.

Yes, apport collects a coredump for crashes. This is the only real way
to have a nice stacktrace done.

But coredumps carry not only a nice (although binary) stack trace. They
may also carry a *lot* more. And this is the reason for the warning
above.

Now, what you forgot to mention is that apport-generated bugs are
opened with blocked access to pretty much *all* (except the reporter).
This access restriction is kept until the back-office apport retracer
runs, generated the stack traces, and *purges* the core dump.

Still, the bug is kept private (but now with a more relaxed access --
developers, and some others, can see it).

Do you know of a better way for doing this? If so, please propose it.

Before apport we tried some other options: let the user generate the
necessary stack trace, do it locally, etc. Tey all failed in getting
correct, *full* stack traces (most would state that debugging symbols
could not be located).

So yes. Apport collects part of the pid memory region. So yes. We warn
that the collected memory areas may contain sensitive data.

But here is the other side of the stick: if apport does not collect the
core dump, and does not generate the stack traces, chances of *EVER*
resolving the issue have now gone astronomically down.

It is, nevertheless an user choice: let apport collect the data,
generate the traces, and delete the binary dump, or not. Keep in mind
that this is almost synonymous with "having a chance of solving a bug,
or not."


> Why do you try to hide this truth and to discredit me?


I am not hiding the truth. I am just providing a more simple
explanation than yours. Which, BTW, happens to be how apport came to be.

I am also not trying to discredit you. I am just trying to make sure
every one here understands your view of this is mostly wrong. No. Your
view is correct, your *explanations* of why are wrong. And the way you
presented them are also wrong.

I can understand being worried about private data being sent over. This
is why I do not make an apport bug public until I have reviewed the
stack traces, and am sure that no private data is being made available.

The whole thing revolves on trust. And trust is based on choice and
knowledge. But it always ends up with a choice being made, correctly or
not (it does not really matter for our discussion).

The difference is searching for knowledge, or accusing us -- the
Ubuntu project -- of being malicious. Which is, at the end, what you
were doing. And which I flatly refuse to accept.

Cheers,

..C..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20160210/16adbb89/attachment.sig>