[Bug binutils/31250] Stripping Rust static libraries fails because of overly zealous illegal path check

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31250

--- Comment #6 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Amyspark from comment #4)
> Applied the patch on top of mingw-w64-binutils (commit
> c2aee7d89488d9402315d59d25852dff258c9eba), and can confirm it works as
> expected.

OK, that is good news.

> Only nit I could propose is to keep track of those files that have been
> basename'd and deduplicate (perhaps by replacing '/'  with '_') in case
> there's a collision between rogue objects.

I thought about doing that, but it makes the patch a lot more complicated and
in the end I think that we are already giving the users a bit too much leeway. 
Still if you find a real world situation where this decision becomes a problem
then I am prepared to revisit the code and make the necessary changes.


(In reply to Amyspark from comment #5)
> >   Is the library really valid if it contains absolute pathnames ?
> 
> Yes, all that MSVC cares about is a) the symbol b) the path inside the .lib
> pointing to an existing object.  

Actually that is a very interesting point.  Does MSVC require that the path
inside the lib point to an object that already exists or one that could exist,
should the element be extract from the library ?  For example suppose that a
library contains an element with the path "E:/foo.obj".  Is it required that
E:/foo.obj also exists outside the library ?  Is the library invalid if the
external version of E:/foo.obj is different from the internal version ?  Is the
library invalid if the host does not have an E: drive ?  What if the library
contained an element with the path "C:/windows/system32/<something>" - surely
such a library would be a huge security risk ?

See PR 17533 where this problem is also discussed:

  https://sourceware.org/bugzilla/show_bug.cgi?id=17533#c4

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.