On Wed, 15 Sep 2010 16:32:57 +0200, Karel Klic wrote:
On 09/15/2010 10:53 AM, Jan Kratochvil wrote:
> Since Fedora 14 GDB supports .gdb_index (by Tom Tromey) and therefore now
> debuginfofs has started to make sense. It made no sense before as GDB read
> the whole .debug file first just to index it; this is no longer true and only
> the small .gdb_index section is being read in.
>
http://fedoraproject.org/wiki/Features/DebuginfoFS
Nice. We should probably set up a test server somewhere to see how it works.
This implementation is for example using FUSE, which I personally do not find
as needlessly complicated and I would prefer. I thought about this project
more as a design principle.
> debuginfofs can provide the same debug info features as an
upload of the whole
> core file; the core upload is not feasible for security reasons.
> Still it means retrace server cannot do the backtracing task, this has to be
> done at the client side - for security reasons.
Can you elaborate on the security reasons, please?
You can trust the retrace server provider like you trust a provider of
cloud computing system, a virtual server, or a web application, can't you?
That is the retrace server must be provided on hosts trusted by fedoraproject
and the communication must be signed by fedoraproject keys, I agree.
(One could think also about a model where the retrace server is not trusted,
from a cloud provided by the Fedora community.)
While it is technically safe I do not feel right to for example send
a cleartext password inisde a core file to a fedoraproject server, do you?
Maybe it is OK, not sure.
Still you need some form of debuginfofs; without the .debug files you cannot
retrieve enough information from the core file for the later retrace by the
retrace server (for example the local variables).
I would probably rather leave the security investigation of the design on the
TH security staff.
Thanks,
Jan