lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+5PVA6S3zLUhL077PXfxdX0=jEa6fvzbygqfyP1eJgv5NSU+Q@mail.gmail.com>
Date:	Fri, 26 Feb 2016 15:38:09 -0500
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: perf install-python_ext installing .o files in python site-packages

Hi Arnaldo,

We've had a report [1] that the python-perf package in Fedora installs
a handful of .o files in /usr/lib64/python2.7/site-packages/.  This is
true on Linus' latest tree, but it goes back to arriving with the 4.2
kernel.

Digging around a bit, it seems the files installed are those that are
found as relative paths in the utils/python-ext-sources directory:

/usr/lib64/python2.7/site-packages/bitmap.o
/usr/lib64/python2.7/site-packages/find_bit.o
/usr/lib64/python2.7/site-packages/hweight.o
/usr/lib64/python2.7/site-packages/rbtree.o

None of those files should really be installed at all, as they're
temporary object files used to build perf.so.

As far as I can tell, this is a side effect of using the python
distutils module with it's setup.py script.  The sources are listed
there so they get included, but then the build_ext functionality
interprets it as e.g.:

-c ../lib/hweight.c -o python_ext_build/tmp/../lib/hweight.o

That leaves it in the lib/ directory of the build output alongside the
final perf.so instead of python_ext_build/tmp/util/ like the rest of
the object files.  It happens to be an unfortunate coincidence that
install-lib looks in said .../lib/ directory and we just happen to
conflict with that naming.  So when install-python_ext is called, it
simply copies everything in that directory, including the .o files.

I'm not enough of a python wizard to figure out how to fix this
quickly.  We could remove the .o files in the .spec file, but that
seems hacky and this should probably be fixed in the perf build
system.

Ideas?

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1312102

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ