Non-fatal 'unsupported hash type'

[Timothy Geiser]

Inkscape 0.92.2 on Windows 7 64-bit
Existing Python installs: both 2.7.10 and 3.4.3 in C:\Python27\ and C:\Python34\ --- but I don't think these are causing any interference.
Uninstalled Inkscape entirely (made sure "C:\Program Files\Inkscape\" does not exist)
Performed normal install ("Optimal" and confirmed that "Python 2.7" is checked) with inkscape-0.92.2-x64.exe
After install, "C:\Program Files\Inkscape\python\" folder exists, but it's **totally empty**.
Confirmed with Process Explorer that a running instance of Inkscape has the PYTHONPATH environment variable set to "C:\Program Files\Inkscape\share\extensions;C:\Program Files\Inkscape\python;C:\Program Files\Inkscape\python\Lib;C:\Program Files\Inkscape\python\DLLs"
That is, this environment variable is pointing to several folders that don't exist.
Open Inkscape
Draw some path, e.g. draw rectangle, Path->Object to Path
With path selected, access from menu Extensions->Visualize Path->Number Nodes...
Keep default settings Font size: 20px, Dot size: 10px, Starting dot number: 1, Step: 1
Click Apply, get below hash errors message
Click OK to dismiss error dialog
Number Nodes command **works just fine**
Some other things that require running python do the same thing (e.g. opening file types that require UniConvertor)
The requested action seems to be completed just fine, but what's up with these errors?
As an aside, why is the PYTHONPATH variable pointing to folders that don't exist? It seems like Inkscape's python install is at "C:\Program Files\Inkscape\lib\python2.7\" even though the python.exe is at just "C:\Program Files\Inkscape\"

Contents of error dialog:

Inkscape has received additional data from the script executed. The script did not return an error, but this may indicate the results will not be as expected.
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512

[Patrick Storz (ede123)]

The errors above indicate an issue with Python not finding or finding the wrong modules. (Hash calculation is a binary component).

As you say you can use uniconvertor (which we do not bundle anymore) this hints towards a different Python being used instead of the bundled Python. There's a good chance the two versions are interfering.

I'd recommend to:
1. Check if you have PYTONPATH or PYTHONHOME environment variables set
   and pointing toward some other Python installation on your system
2. Check which Python is spawned by Inkscape (e.g. with Process Explorer)

Regarding the strange value of PYTHONPATH after launching Inkscape:
This is a side-effect of our changed packaging in 0.92.2 which uses a different directory layout for Python. The environment variables are still set for the old packaging for backwards-compatibility reasons (which does not hurt though as long as "C:\Program Files\Inkscape\python" is empty).

[Timothy Geiser (slimshady007)]

I have UniConvertor installed at "C:\Program Files (x86)\sK1 Project\UniConvertor-1.1.5\" and I copied the uniconv_output.py and uniconv-ext.py files to complete the installation patch to get it working. I skipped this detail in the original bug description as this hash error thing is totally unrelated to UniConvertor itself. This error happens when, apparently, ANY extension that invokes python is run.
I can absolutely confirm that neither PYTHONPATH nor PYTHONHOME environment variables are set on the system.
Process Monitor also confirms that Inkscape is spawning the following command when the Number Nodes... command is run: "C:\Program Files\Inkscape\pythonw.exe" dots.py --id=rect815 --tab=\"Options\" --fontsize=20px --dotsize=10px --start=1 --step=1 C:\Users\username\AppData\Local\Temp\ink_ext_XXXXXX.svgY9D9DZ

I've been able to simplify the process, cutting out Inkscape itself entirely
Open a command window with PWD at C:\Program Files\Inkscape\
Run .\python.exe -v -c "import hashlib"
Get lots of debug info since the -v switch was passed, but still see "ERROR:root:code for hash md5 was not found"
Most of the errors look like the following
  # C:/Program Files/Inkscape/lib/python2.7/site.pyc has bad mtime
  import site # from C:/Program Files/Inkscape/lib/python2.7/site.py
  # can't create C:/Program Files/Inkscape/lib/python2.7/site.pyc
Apparently not everything has bad mtime
  # C:/Program Files/Inkscape/lib/python2.7/linecache.pyc matches C:/Program Files/Inkscape/lib/python2.7/linecache.py
  import linecache # precompiled from C:/Program Files/Inkscape/lib/python2.7/linecache.pyc
The version string is "Python 2.7.13 (default, Jan 17 2017, 13:56:44) [GCC 6.3.0 64 bit (AMD64)] on win32"

You say that hash calculation is binary component. Well, it seems like it's missing or mis-configured under a default Inkscape install.

[Patrick Storz (ede123)]

UniConvertor is very relevant as it installs a complete Python distribution of its own. From the information you gave so far I see no indication that it causes any issues in this case, though.

As this certainly is not an issue with a default Inkscape install I can only guess what's going wrong. My current best guess is that the installation is corrupted for some reason. Did you update your Inkscape distribution (it's possible the update was unsuccessful and some binaries from the old installation are still present in the installation directory)? If this was not a fresh installation and you did not try that before I'd recommend to completely uninstall Inkscape, delete the folder C:/Program Files/Inkscape, and then reinstall.

Another possibility is that the installation is incomplete (e.g. because of interfering security software).

To give you some pointers where to look:
The command above (".\python.exe -v -c "import hashlib"") should at some point output something like
  import hashlib # precompiled from C:\Program Files\Inkscape\lib\python2.7/hashlib.pyc
  import _hashlib # dynamically loaded from C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_hashlib.pyd
What is the output you're seeing instead?
Does the file "\lib\python2.7\lib-dynload/_hashlib.pyd" exist in your installation?

[Timothy Geiser (slimshady007)]

As stated in the initial bug description, this is absolutely a fresh install: "Uninstalled Inkscape entirely (made sure "C:\Program Files\Inkscape\" does not exist)" I did this as a first step since I understand a corrupt installation is a likely culprit and did not want to waste your time.
There *may* be some incompleteness going on as I did not see any "import hashlib" line in the command output.
I ran it -v -v and got this:

...
import atexit # precompiled from C:\Program Files\Inkscape\lib\python2.7/atexit.pyc
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
# trying _sha.pyd
# trying _sha.py
# trying _sha.pyw
# trying _sha.pyc
# trying C:\Program Files\Inkscape\lib\python2.7/_sha.pyd
# trying C:\Program Files\Inkscape\lib\python2.7/_sha.py
# trying C:\Program Files\Inkscape\lib\python2.7/_sha.pyw
# trying C:\Program Files\Inkscape\lib\python2.7/_sha.pyc
# trying C:\Program Files\Inkscape\lib\python2.7\plat-win32/_sha.pyd
# trying C:\Program Files\Inkscape\lib\python2.7\plat-win32/_sha.py
# trying C:\Program Files\Inkscape\lib\python2.7\plat-win32/_sha.pyw
# trying C:\Program Files\Inkscape\lib\python2.7\plat-win32/_sha.pyc
# trying C:\Program Files\Inkscape\lib\python2.7\lib-tk/_sha.pyd
# trying C:\Program Files\Inkscape\lib\python2.7\lib-tk/_sha.py
# trying C:\Program Files\Inkscape\lib\python2.7\lib-tk/_sha.pyw
# trying C:\Program Files\Inkscape\lib\python2.7\lib-tk/_sha.pyc
# trying C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_sha.pyd
# trying C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_sha.py
# trying C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_sha.pyw
# trying C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_sha.pyc
# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/_sha.pyd
# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/_sha.py
# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/_sha.pyw
# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/_sha.pyc
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
# trying _sha256.pyd
<snip a lot of repeated errors for sha256 and sha512>
# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/_sha512.pyc
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "C:\Program Files\Inkscape\lib\python2.7/hashlib.py", line 97, in __get_builtin_construct...

[Patrick Storz (ede123)]

I have absolutely no idea why python does no load _hashlib.pyd for you...

Some things to check
- Have you tried running as administrator?
- Have you checked file/folder permissions?
  (maybe try to run from an unrestricted location)
- Have you tried disabling all security software?
  (maybe file access is blocked for some reason)

Attached is the full output from my machine. As you can see loading the required libraries seems pretty much straightforward here. Maybe you can compare with your output to see if there are any differences that could explain the differing behavior.

[Timothy Geiser (slimshady007)]

There's something with the order things are trying to be loaded. Your file looks like:

# trying C:\Program Files\Inkscape\lib\python2.7\site-packages/usercustomize.pyc
Python 2.7.13 (default, Jan 17 2017, 13:56:44) [GCC 6.3.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
# trying hashlib.pyd

The Python version string appears before it tries to find hashlib (unless this -v output doesn't make guarantees about ordering...)
Mine shows up way before that.
Yours doesn't even have atexit.
Can you take a full look at my output?

[Patrick Storz (ede123)]

Well, the "atexit" parts are probably exclusive to your output because there's an exception + traceback for you but probably unrelated to the actual issue.

The one potentially relevant difference I can see is immediately after Python prints its version string:

# trying runpy.pyd
# trying runpy.py
# trying runpy.pyw
# trying runpy.pyc
# trying C:\Program Files\Inkscape\lib\python2.7/runpy.pyd
# trying C:\Program Files\Inkscape\lib\python2.7/runpy.py
# C:\Program Files\Inkscape\lib\python2.7/runpy.pyc matches C:\Program Files\Inkscape\lib\python2.7/runpy.py
import runpy # precompiled from C:\Program Files\Inkscape\lib\python2.7/runpy.pyc
import imp # builtin
# trying pkgutil.pyd
# trying pkgutil.py
# trying pkgutil.pyw
# trying pkgutil.pyc
# trying C:\Program Files\Inkscape\lib\python2.7/pkgutil.pyd
# trying C:\Program Files\Inkscape\lib\python2.7/pkgutil.py
# C:\Program Files\Inkscape\lib\python2.7/pkgutil.pyc matches C:\Program Files\Inkscape\lib\python2.7/pkgutil.py
import pkgutil # precompiled from C:\Program Files\Inkscape\lib\python2.7/pkgutil.pyc

Python does not seem to load "runpy.py" or "pkgutil.py" for me (at least it's not explicitly mentioned anywhere in the output) and both are in fact related to importing and locating modules!

Immediately after I have
  import hashlib # precompiled from C:\Program Files\Inkscape\lib\python2.7/hashlib.pyc
and then
  import _hashlib # dynamically loaded from C:\Program Files\Inkscape\lib\python2.7\lib-dynload/_hashlib.pyd

You have neither of those, so this seems to be where it goes wrong, but from the output it's absolutely unclear to me why it fails and why your Python seems to load different modules

Maybe you can check your environment variables again, to see if there's anything relevant?
(you can use "env" on the command line to produce attachable output)
Also maybe something in your user configuration on disk (I'm not sure where it is located but it's one of the few things I can imagine)

[Timothy Geiser (slimshady007)]

Found a solution: Copy C:\Program Files\Inkscape\libeay32.dll to \C:\Program Files\Inkscape\lib\python2.7\libeay32.dll
I did some digging with Process Explorer on a computer that has Inkscape-bundled python working and found that it was looking for this DLL in the following search order:

C:\Program Files\Inkscape\lib\python2.7\LIBEAY32.dll
C:\Windows\System32\LIBEAY32.dll
C:\Windows\System\LIBEAY32.dll
C:\Windows\LIBEAY32.dll
C:\Program Files\Inkscape\libeay32.dll
<may be more after, but this last one should be found, and was on this working computer>

On the failing computer, C:\Windows\System32\LIBEAY32.dll does exist, but it is waaayyy out of date and must not be the right thing for Inkscape-bundled python. The bug-fix for this is almost certainly to change the search order to look sooner for C:\Program Files\Inkscape\libeay32.dll

On a site note, my system installed Python2.7 has a much larger _hashlib.pyd that includes the code inside it, so it doesn't go looking for LIBEAY32.dll at all, and thus doesn't get tripped up.

[Patrick Storz (ede123)]

Thanks, that's very helpful information!

Can you try the following build and see if it solves the issue (i.e. works without copying the .dll)?
  https://ci.appveyor.com/project/Ede123/inkscape/build/0.92.x-491
(chose MING32/64 for 32/64-bit, then click artifacts and download the .7z package)

> I did some digging with Process Explorer [...]

For my personal curiosity: How did you do that? Or did you mean Process Monitor?

> On a site note, my system installed Python2.7 has a much larger _hashlib.pyd

The official CPython distribution uses statically linked binaries.
We use MSYS2's mingw-w64 build which uses dynamically linked libraries and therefore relies on some additional .dlls

[Timothy Geiser (slimshady007)]

I tried this build and it still suffers the same issue. It still ran a search order of:

  C:\Program Files\Inkscape\lib\python2.7\LIBEAY32.dll
  C:\Windows\System32\LIBEAY32.dll **if found here, then search stops**
  C:\Windows\System\LIBEAY32.dll
  C:\Windows\LIBEAY32.dll
  C:\Program Files\Inkscape\libeay32.dll **if none of the above, this one is
    actually present and never has to search any farther than this, but this
    was working even before your patch**

PYTHONPATH = C:\Program Files\Inkscape\share\extensions;C:\Program Files\Inkscape\python;C:\Program Files\Inkscape\python\Lib;C:\Program Files\Inkscape\python\DLLs;C:\Program Files\Inkscape

I read the comment on the patch 2ca42803 about changing the PYTHONPATH, and although it now includes the Inkscape root folder, it looks like PYTHONPATH is not affecting the DLL search order.

I was actually able to remove my old/wrong C:\Windows\System32\LIBEAY32.dll without breaking anything (it was in use by some old HP software I have; I just moved it into the same folder as the EXE that was using it and it still runs fine this way). This sort of thing is still a "bug" in the sense that a perfectly reasonable alternate system-wide installed libeay32.dll can trip python up.

On that note:
> We use MSYS2's mingw-w64 build which uses dynamically linked libraries and therefore relies on some additional .dlls
Oh, yikes. Well, looks like I can break at least two other things now. System-wide but possibly incompatible versions of:
  zlib1.dll -> breaks at least binascii and lxml.etree, but not zlib
  libexslt-0.dll -> breaks at least (and probably only) lxml.etree
  libxslt-1.dll -> lxml.etree
  libxml2-2.dll -> lxml.etree
  libiconv-2.dll -> lxml.etree
  liblzma-5.dll -> lxml.etree
may cause problems, assuming that the python code to be run requires those things and that the system-wide DLLs are not correct/compatible.

You should be able to test this DLL search path stuff yourself. Just create an empty (0 byte) file at C:\Windows\System32\LIBEAY32.dll (or C:\Windows\System\LIBEAY32.dll or C:\Windows\LIBEAY32.dll) to simulate an incorrect/incompatible DLL and give it a whirl. That should be enough to reproduce the same thing. I want to thank you for your help and attention to this issue, and would be happy to continue helping test/troubleshoot, but thought it would be easier for you to be able to reproduce the entire situation on your own.
What's got me stumped is how to fix this at all. I have no clue how to modify this DLL search order to be more like:

  C:\Program Files\Inkscape\lib\python2.7\LIBEAY32.dll
  C:\Program Files\Inkscape\libeay32.dll **This always gets found here and
    prevents the system paths from ever being searched**
  C:\Windows\System32\LIBEAY32.dll
  C:\Windows\System\LIBEAY32.dll
  C:\Windows\LIBEAY32.dll

> Or did you mean Process Monitor?
Yes, I meant Process Monitor. I use Process Explorer every day, so I mis-remembered their names.

[Patrick Storz (ede123)]

OK, different approach this time:
  https://ci.appveyor.com/project/Ede123/inkscape/build/0.92.x_pythonpath-496
According to my tests this should work fine now.

Turns out we can add to PATH and PYTHONPATH whatever we want - system paths will always be searched first. The fix I added now makes sure the inkscape root directory will be searched for DLLs early on and seems to fix the issue.

See also https://github.com/numpy/numpy/wiki/windows-dll-notes for a nice write-up of the issue.

I additionally created an issue upstream to get some feedback on how this issue might be solved in a more general way, see https://github.com/Alexpux/MINGW-packages/issues/3343

[Patrick Storz (ede123)]

Did you have a chance to check the patched binaries?

If it solves your issue I tend to commit the changes to master and the stable branch.

[Timothy Geiser (slimshady007)]

Yes, this appears to allow Inkscape to spawn a pythonw.exe with a DLL search order of:

C:\Program Files\Inkscape\lib\python2.7\LIBEAY32.dll
C:\Program Files\Inkscape\libeay32.dll

So this is working as the second path is good. I tried the Number Nodes... command from within Inkscape for this.
I was thrown off at first as I tried to just run 'C:\Program Files\Inkscape\python.exe -c "import hashlib"' from a console as an exercise/test and it was still not working. I looked at your patch and realized it has something to do with the fact that the DLL path is adjusted from inside Inkscape and that python is spawned as a child of it.
You should be able to commit this change, as strictly speaking it's not necessary to python as run from the console be correct, just to have Inkscape spawned processes behave.

[Patrick Storz (ede123)]

OK, thanks for confirmation.

WRT to python itself we are still discussing upstream what the best solution would be (changing the load order of DLL can obviously have a lot of undesired side effects) but for Inkscape the changed search order should always be what we want, so we should be sage (I hope :-D ).

[Patrick Storz (ede123)]

*sage -> safe

[Patrick Storz (ede123)]

Fix commited to master in
  https://gitlab.com/inkscape/inkscape/commit/ecfc9efaf66d054fda239f48ef984190a89e6bae
and backported to 0.92.x in
  https://gitlab.com/inkscape/inkscape/commit/af69bd0273278f2fa31a4d5373ab624dc78824ba

Any remaining issues let us know!