We Keep Coding

macOS trusts Python whl files, but not tar files

I provide my python c extension as both as a tar file, as well as a whl file.
On macOS, I am surprised that there are no problems installing the wheel for my extension. When setting PYTHONPATH to my python extension in the tarball, I am immediately met with the dialog about unverified developers.
Could someone please explain why macOS trusts my unsigned python extension, but has no problem if I package it in a wheel file.
Update: This is the error I see after I close the dialog box:
>>> import devsim
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jsanchez/Downloads/devsim_macos_v2.3.7rc1/lib/devsim/__init__.py", line 8, in <module>
from .devsim_py3 import *
ImportError: dlopen(/Users/jsanchez/Downloads/devsim_macos_v2.3.7rc1/lib/devsim/devsim_py3.so, 0x0002): tried: '/Users/jsanchez/Downloads/devsim_macos_v2.3.7rc1/lib/devsim/devsim_py3.so' (code signature in <ED44BB00-36CF-39A8-8999-8309CBA016E4> '/Users/jsanchez/Downloads/devsim_macos_v2.3.7rc1/lib/devsim/devsim_py3.so' not valid for use in process: library load disallowed by system policy)
Could someone please explain why macOS trusts my unsigned python extension, but has no problem if I package it in a wheel file.
Update 2:
From what I can see. If I download the tgz to my Downloads folder using Chrome, I am getting the error. If I download the tgz using curl, it works. I am thinking that Chrome is adding this bad attribute.

Thanks to #GordonDavisson for his tip concerning the attributes. It turns out the issue was related to google chrome. If I download the file from Github using Chrome I get:
com.apple.macl 72
com.apple.metadata:kMDItemWhereFroms 655
com.apple.quarantine 57
and using curl I get no attributes.
I have lax security permissions in Chrome (no safe browsing), but this still occurs. I will be sure to look out for this the next time I encounter it.
Update
I found this very useful post concerning the current macOS landscape:
https://eclecticlight.co/2021/02/18/code-signing-requirements-for-scripts-and-apps-in-big-sur/

ImportError of module libscrc on Raspberry Pi 3

I'm kinda new to Rpi's and I have a problem executing a library called libscrc with python (I use python3), I need this to calculate a crc checksum for my RS485 communication. On pycharm on my PC everything works fine, but when I implement this on my RPI3 I get errors, I already managed to install the pyserial library and this works fine, but I keep getting errors when trying to run libscrc (this is the link to the library: https://pypi.org/project/libscrc/ ). This is the error:
Traceback (most recent call last):
File "Rs_485.py", line 1, in <module>
import libscrc
File "/home/pi/.local/lib/python3.6/site-packages/libscrc/__init__.py", line 14, in <module>
from ._crcx import *
ImportError: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory
Can anyone help me? I already updated and upgraded the RPI.
When I try the following test command
pi#raspberrypi:~/codes $ python -m libscrc.testmodbus
I get:
/usr/bin/python: No module named libscrc
And I'm using python3.6 by the way

Give it a try by using the github link of the libscrc project
!pip install git+https://github.com/hex-in/libscrc.git
It worked this way for me! cheers!

The answer was found! Hope this wil help anyone out with the same problem!
Use this command!:
sudo apt-get install libpython3.6
this did the job for me! :)

LD_preload for using other versions of libc, isn't working in pwntools

I want to use other versions of library for my pwn study in pwntools, but EOF error occurred.
I tried to solve this issue , changed ubuntu versions 3 times (18.04 desktop -> 14.04 desktop -> 18.04.0 server), reinstall python and pwntools 4 times.
currently, versions are ubuntu 18.04.0 server, Python 2.7.15rc1, pwntools 3.12.2
I tried using other versions library for my pwn study in pwntools.
like this:
p = process("./binary_name",env={"LD_PRELOAD" : "./libc_name"})
and tried also
env = {"LD_PRELOAD": os.path.join(os.getcwd(), "libc_name")}
p = process("./binary_name",env=env)
and excute python code, Error occurred
I already set the permisson of libc to chmod 777, but result is same.
[*] Process './aeiou' stopped with exit code -4 (SIGILL) (pid 77469)
Traceback (most recent call last):
File "ex4.py", line 6, in <module>
p.sendlineafter(">>","3")
File "/home/synod2/.local/lib/python2.7/site- packages/pwnlib/tubes/tube.py", line 747, in sendlineafter
~~~~~~~~~~~~~~
EOFError
I dont know why EOF error occurred. but, because of 3 differents version ubuntu give the same error, I think I missed install something.
but I don't know what I missed!

Maybe you should try it on Ubuntu 16.
Obviously your binary file is dynamic linked. So when the program need to call some libc function such as read. It will pass some information to the dynamic linker, then the linker will calculate the real address of the read function.
but functions in libc has a version attribute. So if you try to use LD_PRELOAD on Ubuntu 18.04. the dynamic linker would try to find sth like read_2_27 in you 2.23-version-libc which only have read_2_23. so your program would fail to execute.
UPDATE:
another solution is to tell the excutable file to use the correct version of ld.so
elf file has a segment(INTERP) in which save the path to the ld.so to use. you can just change it to the path to ld.so you want to use.
BTW, you can find many version of ld.so in the repository

Python: Installing and using Exscript module Windows x86

I have been banging my head against the wall trying to get Exscript installed. After multiple failed attempts at doing it manually, I installed ActivePython and had success running "pypm install Exscript" from the cmd prompt.
I am now going through the Exscript documentation (found here https://github.com/knipknap/exscript/wiki/Python-API-Tutorial) and if I run the first example script I get an error:
>>> from Exscript.util.interact import read_login
Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
from Exscript.util.interact import read_login
ImportError: No module named interact
So, I understand that this is saying that there is no module interact. How can I check this? Is there a way I can manually add this module? I would love to know WHY this module didnt come with the package, but that may be impossible to answer :)
Any and all help is greatly appreciated. Thank you
EDIT -
import Exscript.util works but if I try import Exscript.util.Interact I get the error. When I look in util.py I see an entry that says "from FooLib import Interact". I first thought it may just be a capitalization error (Exscript.util.interact vs util.Interact) but neither of those work. I am not sure where to go from here... :(
EDIT -
I have posted this question on the developers forums, hopefully he will have an answer for us. https://github.com/knipknap/exscript/issues/15
EDIT -
The developer suggested that I was using an old version and told me to download the latest. I had struggled installing the module manually so I googled how to easily install py modules. I found a writeup on easy_install.exe. I ran "c:\Python26>easy_install C:\Users\support\Desktop\lou\knipknap-exscript-v2.1-70-gf5583f3.tar.gz" from the cmd prompt, the module was installed (no errors) and now when i run the script it works.
Next challenge will be how to get these scripts to run as stand-alone exe's on users computers without Python installed :)
THANK YOU to everyone to commented I truely appreciate your help.
Lou

One common way packages are installed is as directories. So check your site-packages directory for an Exscript directory, and inside that there should be a util directory, and inside that there should be an interact.py file. Look for similar spellings in case the tutorial misspelled something.

How can I tell python which version of libmysqlclient.so to use?

I'm running a python script on a shared hosting server which until this morning had MySQL version 4. Now it has version 5. My python script can no longer connect to MySQL, as it can't find libmysqlclient_r.so.14:
$ python my_script.py
Traceback (most recent call last):
File "my_script.py", line 6, in ?
import MySQLdb
File "/home/lib/python2.4/site-packages/PIL-1.1.6-py2.4-linux-i686.egg/__init__.py", line 19, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 7, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient_r.so.14: cannot open shared object file: No such file or directory
There are various other versions of libmysqlclient in /usr/lib:
/usr/lib/libmysqlclient.so.15
/usr/lib/libmysqlclient.so.14
/usr/lib/mysql/libmysqlclient.la
/usr/lib/mysql/libmysqlclient.so
/usr/lib/mysql/libmysqlclient_r.so
/usr/lib/mysql/libmysqlclient_r.a
/usr/lib/mysql/libmysqlclient_r.la
/usr/lib/mysql/libmysqlclient.a
/usr/lib/libmysqlclient.so
/usr/lib/libmysqlclient_r.so
/usr/lib/libmysqlclient_r.so.15
/usr/lib/libmysqlclient_r.so.15.0.0
/usr/lib/libmysqlclient.so.15.0.0
So my question is this: how can I tell python (version 2.4.3) which version of libmysqlclient to use?

You can't tell the dynamic linker which version of a library to use, because the SONAME (full name of the library + interface) is part of the binary.
In your case, you can try to upload libmysqlclient_r.so.14 to the host and set LD_LIBRARY_PATH accordingly, so tell the dynamic linker which directories to search additionally to the system dirs when resolving shared objects.
You can use ldd to see if it LD_LIBRARY_PATH works:
$ ldd $path_to/_mysql.so
...
libmysqlclient_r.so.14 => $path_to_lib/libmysqlclient_r.so.14
...
Otherwise, there will be an error message about unresolved shared objects.
Of course that can only be a temporary fix until you rebuild MySQLdb to use the new libraries.

You will have to recompile python-mysql (aka MySQLdb) to get it to link to the new version of libmysqlclient.
If your host originally set up the environment rather than you compiling it, you'll have to pester them.
/usr/lib/libmysqlclient.so.14
This looks like a remnant of the old libmysqlclient, and should be removed. The _r and .a (static) versions are gone and you don't really want a mixture of libraries still around, it will only risk confusing automake.
Whilst you could make a symbolic link from libmysqlclient_r.so.14 to .15, that'd only work if the new version of the client happened to have the same ABI for the functions you wanted to use as the old - and that's pretty unlikely, as that's the whole point of changing the version number.

One solution is to set your PYTHONPATH environment variable to have some local directory, and copy over (or link, I suppose) the version of the mysql lib you want.