summary Allow user to suppress individual fields when sending a report
status triaged
importance low
done
Brian J. Murrell [2008-10-28 11:16 -]:
> > > I should be able to deselect sending any of the stack trace
> > > attachments too.
> >
> > That's a possible enhancement indeed.
>
> Do t
On Tue, 2008-10-28 at 09:58 +, Martin Pitt wrote:
> Hi Brian,
Hi Martin,
> Right. Just to be clear, I am not *really* happy about sending core
> dumps either, but it's currently the only practical method to get any
> helpful information out of most crashes.
Understood.
> If the stack trace
Hi Brian,
Brian J. Murrell [2008-10-23 20:50 -]:
> Indeed. But I can visually inspect stack traces. I cannot do that with
> the CoreDump.
Right. Just to be clear, I am not *really* happy about sending core
dumps either, but it's currently the only practical method to get any
helpful informa
On Thu, 2008-10-23 at 19:50 +, Martin Pitt wrote:
> That's of course important supplementary data, but on its own it is
> worthless to describe the problem, yes.
Of course, however along with...
> Stack traces can already contain pretty much anything, passwords, PIN
> numbers, secret project
Brian J. Murrell [2008-10-23 18:17 -]:
> So knowing the package versions, distro release version
That's of course important supplementary data, but on its own it is
worthless to describe the problem, yes.
> and having stack traces
Stack traces can already contain pretty much anything, passw
On Thu, 2008-10-23 at 17:59 +, Martin Pitt wrote:
>
> How should it? There isn't a single place which holds/knows all your
> passwords, secret projects, personal data, and other sensitive stuff,
> except maybe your brain.
Sure. The keyring potentially has a wealth of them, yes. Perhaps
appo
> If apport (the interacting with the user part) knows the password(s)
that could be in any attachment it can scrub them.
How should it? There isn't a single place which holds/knows all your
passwords, secret projects, personal data, and other sensitive stuff,
except maybe your brain.
> The real
Martin,
Seriously? "Yes, it's a problem but we don't know how to fix it, so we
will just close it"?
As for "https://launchpad.net/ubuntu/+spec/crash-reporting"; that does
not solve the problem. My passwords are still in LP's database and only
as safe as LP is secure (which I have no reason to b
If apport (the interacting with the user part) knows the password(s)
that could be in any attachment it can scrub them.
The question is whether to expose passwords to apport or not.
--
should try to sanitize passwords from attachments
https://bugs.launchpad.net/bugs/107103
You received this bug
I confirm that both stack traces and core dumps can potentially have
stack traces. However, there is no reliable way of detecting passwords
automatically, thus I better close this one.
The better solution is to not expose these things to the public bug
tracker in the first place, see https://launc
On Mon, 2007-16-04 at 22:29 +, Marco Rodrigues wrote:
> Have you an example of this ? I think it doesn't includes that type of
> information...
A coredump of a login process dying or screen-saver unlocking process
will most certainly contain a password. Trust me. I have a core dump
here in h
Have you an example of this ? I think it doesn't includes that type of
information...
--
should try to sanitize passwords from attachments
https://bugs.launchpad.net/bugs/107103
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
u
** Changed in: apport (Ubuntu)
Status: Unconfirmed => Needs Info
--
should try to sanitize passwords from attachments
https://bugs.launchpad.net/bugs/107103
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mai
13 matches
Mail list logo
