Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make importable from Crypto and Cryptodome by default #613

Open
Evidlo opened this issue Apr 11, 2022 · 4 comments
Open

Make importable from Crypto and Cryptodome by default #613

Evidlo opened this issue Apr 11, 2022 · 4 comments

Comments

@Evidlo
Copy link

Evidlo commented Apr 11, 2022

Many modern packages depend on pycryptodome, which is recommended as the 'default' replacement for pycrypto.

As pycryptodome is a superset of the algorithms featured in pycrypto, it's important for these packages that we don't accidentally import pycrypto, otherwise things may break unexpectedly at runtime.

This is normally what pycryptodomex package is for. However, most distributions don't bother packaging it:

# Debian 11 Bullseye
[evan@blackbox ~] apt search cryptodomex
Sorting... Done
Full Text Search... Done

# Ubuntu 20.04
[evan@tikhonov ~] apt search cryptodomex
Sorting... Done
Full Text Search... Done

If use_separate_namespace is made True in setup.py, then the default package will provide both the Crypto and Cryptodome modules, obviating the need for pycryptodomex.

@Evidlo Evidlo changed the title Make .separate_namespace default Make use_separate_namespace=True default Apr 11, 2022
@Evidlo
Copy link
Author

Evidlo commented Apr 12, 2022

Relevant issues in my packages:
libkeepass/pykeepass#302
libkeepass/pykeepass#232

@Evidlo Evidlo changed the title Make use_separate_namespace=True default Make importable from Crypto and Cryptodome by default Apr 12, 2022
@Evidlo
Copy link
Author

Evidlo commented May 24, 2022

Any thoughts on this?

@Varbin
Copy link
Contributor

Varbin commented Jun 4, 2022

@Evidlo Simply making it available under two namespaces might be difficult, as it will not allow the parallel usage of PyCrtypto and Pycryotodome. I could imagine the following: The Pycryptodomex continues to exist as before, but Pycryptodome changes to be a simple shim depending on Pycryptodomex. This ensures the Cryptodome namespace will be always available.

Anyway I don't know if this is an issue at all. Debian does indeed use the Cryptodome namespace, as it was possible -- up to Debian 10 I think -- to install PyCrypto and Pycryptodome in parallel. On RedHat based systems, the package is already known as python(2|3|)-pycryptodomex which provides the Cryptodome namespace only as well.

@eli-schwartz
Copy link

What is the valid use case of continuing to support parallel installation of PyCrypto? It is unmaintained since 2014, does not run correctly on multiple counts with modern versions of python, does not build at all with current versions of setuptools, has various security vulnerabilities which will never be fixed, and as of the beginning of this year, has received the first commits in nearly a decade... which are an update to the README pointing people at pycryptodome, followed by archiving the repository.

It's official. PyCrypto is so dead it's telling people that it is dead and should not be used. Victory has been achieved; all uses of import Crypto MUST be using cryptodome.

It makes sense to take over that import namespace, have both versions provide both imports, and make one of the PyPI names into a "legacy name".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants