Re: rewrite try_dlopen (1)

[Gary V. Vaughan]

Tag Ralf!

Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Mon, Oct 04, 2004 at 02:05:24AM CEST:
> > Might I suggest having a struct to hold the parsed la file, both
> > to reduce the number of pass-by-reference parameters, and to make
> > the function interface stable in the face of a changing .la spec.
> 
> Yes.  That was one idea.  It's orthogonal to this patch, though, and
> possibly more functions can benefit from that idea.

True enough.

> > If you feel like making notes on a formal specification
> > for .la files for a future revision, that would be even cooler ;-)
> 
> Yes.  For the semantics, I sense the discussion is not over (ever will
> be?).

Indeed, I am sure things will continue to change in that respect as we add new
features and supported hosts.

>  But for the syntax, I'm thinking along these lines:
> 
> - it must be Bourne-shell source-able.
> - A line is either
>     empty
>     a comment (starts with #)
>     or a (complete!) variable assignment.
> - The right-hand side of a variable assignment should either be
>     single-quoted
>     or not quoted at all (and consist of one word only).

There are some double quoted fields in the .la files I just glanced at
(relink_command in this case), though there is no reason that particular case
couldn't use single quotes.  I think it is a good idea to specify that to
reduce surprises from shell expansion.

> - The libltdl parsing *must* yield the same value as shell sourcing
>   in case that
>     no variable expansions are used ($foo)
>     no shell wildcards are used (libfoo*)
>     no config.status expansions are used (@foo@)

Are you saying that these constructs should not be used?  I'm not sure I agree
with that, and again I've found @inst_prefix_dir@ in a libltdl.la file, so we
use that construct at least.

Maybe you're just saying that the shell sourcing can only be identical to the
parser read value when these constructs are not used.  I do agree with that.

>   All these cases I'd like to leave undefined (as a possible way of
>   extending the defined syntax later on) for libltdl at least.
> - libltdl should not crash even on bogus .la files.  This requirement
>   stems from the goal of third-parties eventually being able to write
>   such files.  Besides, I have a tendency of thinking of all input files
>   as unverified (thus, treat them as potentially malicious).

Most definitely.  We should take a lot more care to security audit the code of
a new parser against accidentally running malicious code from a .la file.  I'm
not sure there is much we can do when sourcing the .la file from the libtool
script... maybe we should grep out assignments, and only source those lines.
Hmmm, then again, I don't think that buys us much.  If someone wants to
subvert a .la file, they will need to change the content of the variables that
are run by root (like the relink_command).

> Any objections against these?  I think they are backwards-compatible in
> the sense that newer libltdl should be able to read older .la files this
> way.

Apart from my comments above (which are probably just a misunderstanding on my
part), no objections from me.

> BTW, the rewrite process has already revealed more than one of crashing
> the parsing code...  and I hate things such as sensitivity to trailing
> white space (e.g. `installed=yes ').

I'm not at all surprised.  I still don't quite understand how the inner
recursive calls of tryall_dlopen interact :-(

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature