It looks like Big Sur removed `libcrypto.dylib` as a file on the
filesystem, so loading it using `ctypes.find_library` fails which breaks
Kindle decryption. Now to load a dylib you need to attempt to load it
directly and the operating system will load the dylib from the OS' cache
or fail.
This fixes the problem by explicitly setting the path to libcrypto to
`/usr/lib/libcrypto.dylib` if `ctypes.find_library` does not find the
file, loading the dylib and raising an exception if it fails at that
point.
See saltstack/salt#5778 for more detailed info.
Closes#1369.
Without this, it's possible for the Linux PYTHONPATH to leak through
and mixing up the PyCrypto libraries being called (or possibly
exceeding the allowed length of the PYTHONPATH in wine).
In order to properly get pids etc. we need to pass bytes to MD5 and SHA1
instead of unicode strings. Also ord() is no longer needed since
data is bytes value gets int and we need chr() to get characters from
the mapping bytearrays.
As I already said prompt is the right word so yeah...
and "you are use kindle" is making no sense so replacing it to make it meaningful i.e. "If you are using the Kindle for PC under Wine"
I think it may be a silly mistake or something because the other prompts are written well except this. Just to webpage will not look authentic by using a wrong spelling so writing the sentence like as follows :
Clicking this button will prompt you to enter a new name for the highlighted key in the list.
THIS IS ON THE MASTER BRANCH. The Master branch will be Python 3.0 from now on. While Python 2.7 support will not be deliberately broken, all efforts should now focus on Python 3.0 compatibility.
I can see a lot of work has been done. There's more to do. I've bumped the version number of everything I came across to the next major number for Python 3.0 compatibility indication.
Thanks everyone. I hope to update here at least once a week until we have a stable 7.0 release for calibre 5.0
`ebook-convert` converts ebooks without adding them to the calibre library, and so dedrm_tools fails to run and convert books that are processed in this way. Adding on_preprocess means that it will also run on any preprocessing allowing these tools to be used by the cli tools.
As far as I'm aware, there's nothing wrong with having this run in both instances, and it still seems to allow conversion in the "standard way".
decrypting as python2 work
failing with python3:
File "ineptepub.py", line 424, in decryptBook
bookkey = rsa.decrypt(bookkey.decode('base64'))
AttributeError: 'str' object has no attribute 'decode'