Re: [gpsd-dev] chrpath dependency

[Christian Gagneraud]

On 11/22/2013 12:33 PM, Eric S. Raymond wrote:
> Christian Gagneraud <address@hidden>:
> > I think the Sconstruct needs some cleanup:
> > - make the test apps depends on the static libs only
> > - ensure that the test apps are linked against the static libs even
> > if the shared one are already built or not

I just started on that one, it was actually easy to do (see attached patch).
So now things get built correctly but the tests using gpsfake are broken 
for some reasons I still ignore (I got connection refused[1]).

Now I'm writing this email because I think this is all going nowhere, 
i'm not sure it is worth spending time on the connection refused problem 
given the fact that gpsfake invoke gpsd, which is still dynamically 
linked, and as such defeat the purpose of this idea (get rid of chrpath 
by using statically linkage).

My opinion is that Eric "may be over-optimizing a bit here." when it 
comes to security (I had to make it, sorry! ;))

OK, seriously:
- Should we build a static gpsd too? But, then, who knows who is the 
next on the list?
- The test framework will still have the same kind of vulnerability 
(needs to tweak PYTHONPATH to load the .so bindings)

Maybe the solution is to make chrpath a hard dependency, scons fails if 
it is not detected, and get rid of all the static stuff in SConstruct

BTW, it is quite common (at least in the embedded world) to package 
tests as well, in that case you would prefer dynamically linked tests.

Chris

[1] If anyone fancy, i can send him/her the full strace log of a testcase.

static-linkage-of-test-apps.patch
Description: Text Data