On 2018-02-07 02:54 PM, Sergio Durigan Junior wrote:
> Unfortunately it seems that "file" is not "properly maintained" in
> the sense that the project doesn't have a trivial way to receive 
> contributions.

But it does help when list members like Chris know the original
developer and can get you the contact details of the
most-upstream-of-all maintainer! Unfortunately, the maintainer doesn't
consider it a bug:

>>> Thanks for the bug report; only this is not a bug. PIE
>>> executables are shared objects. There is no way to tell them
>>> apart from shared objects.

So we're kind of stuck.

> In this scenario, what I recommend is to file a bug downstream
> (against Debian's "file", for example), and ask the maintainer to
> forward the fix upstream.

I did, with Ubuntu:

Unfortunately, if this really isn't something that the file (1)
maintainers can fix, I'm going to have to file bugs with the Gnome
Files/Nautilus (Gnome), PCManFM (LXDE), Konqueror (KDE) and Thunar
(XFCE) folks to advise them not to rely on magic (5) alone now.

> It seems to me that perhaps the graphical UI could rely not only on
> the MIME type of a file, but also if it is marked as executable or
> not.

That would be sensible, yes.

>  Debian explicitly advises (in the form of a lintian error)
> against having the executable bit set for libraries, so only
> executable files will have +x.

But now we'll need to fix lintian, as Debian binaries are being supplied
as shared objects. If you've got a recently-updated Debian Stretch
distro running, binaries such as /usr/bin/curl are PIE shared objects …

> Yeah, this is not really a workaround per se, because it disables
> PIE when compiling the binary.  Having PIE enabled is a nice
> security feature, so I would recommend against doing that.

For sure. But since naïve users (and me ☺) use graphical file managers,
and the only way to get binaries to run these days is to make them
non-PIE, we have a security problem.

Talk Mailing List

Reply via email to