Re: [patch] New set auto-load-local-gdbinit + disable it by default

Doug Evans
2012-01-17T19:02:38Z

On Tue, Jan 17, 2012 at 10:42 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 17 Jan 2012 19:29:04 +0100, Doug Evans wrote:
>> > It is difficult to argue myself but IMO in a survey between GDB newbies they
>> > find easier if GDB behaves always the same than if it behaves differently
>> > according to which program you load into it.
>>
>> Which survey is that?  Is it online?
>
> Unfortunately I do not know about any.  I was just guessing results of
> a hypothetical survey.  Sorry for being unclear.

I wouldn't want to make such a substantial change based on a guess.

>> [And I'm curious once they understand what's going on, what do they prefer.
>> Every new thing involves a bit of a learning curve ...
>
> If anything requires a needless learning curve it will be changed.

Depends on the result, inclusion of the word "needless" is a strawman argument.

>> I'd be curious to know what the long term cost/benefit is for these newbies
>> in addition to just the short term ... Once they understand it, do they
>> prefer it?]
>
> They do not need to understand it.  They just already use and develop other
> debuggers.
>
>
>> Script it.
>
> If you prefer it in FSF GDB as a script I am can code it that way.
>
>
>> Too complicated how?
>
> I find
>
> (a) Extract first and second argument in shell, that will be several lines of
>    code.
> (b) exec gdb -nx -x /etc/gdbinit -x ~/.gdbinit -ex "set auto-load-scripts off" -ex "set libthread-db-search-path" -ex "file $file -ex "core-file $corefile" "$@"
>
> as more complicated than
>
> gdb -secure "$@"
>
> Don't you?

As opposed to a script named, say, secure-gdb that did that?

>> Write the script once and you're done.
>> If we had a contrib-like directory we could even ship one with gdb.
>
> I have to ship it anyway so either Fedora + Red Hat will have to fork again or
> it needs to be shipped with gdb.  It is a normal task of developers to analyze
> shipped crashes/binaries.

Maintenance of pure additions is far easier than maintenance of local
mods that involve changes.
And maintenance of pure additions that are simply new files is easier than that.
IOW, if Fedora had to ship a script that wasn't in FSF GDB, is it
really that big a deal?
[OTOH, I for one, wish we had a contrib-like directory.]

>> Are we sure we want to claim to the user community -safe is, umm, safe?
>> It seems like we're a fair ways from being ready to claim it, setting
>> aside auto-loading.
>
> If we are not ready for -safe then we should not.
>
> I am aware of DWARF reading unhandled run-offs but that is AFAIK only DoS
> category of exploit.
>
> Are you aware of any new exploits?  This Python/libthread_db is CVE-2011-4355.

My point is a security audit of GDB is more than just fixing the bugs
we know of.
As is taking on the job of keeping it that way.