Spec URL: https://ignatenkobrain.fedorapeople.org/for-review/python-pycryptodome.spec SRPM URL: https://ignatenkobrain.fedorapeople.org/for-review/python-pycryptodome-3.4.2-1.fc26.src.rpm Description: PyCryptodome is a fork of PyCrypto. It brings the following enhancements with respect to the last official version of PyCrypto (2.6.1): * Authenticated encryption modes (GCM, CCM, EAX, SIV, OCB) * Accelerated AES on Intel platforms via AES-NI * First class support for PyPy * Elliptic curves cryptography (NIST P-256 curve only) * Better and more compact API (nonce and iv attributes for ciphers, automatic generation of random nonces and IVs, simplified CTR cipher mode, and more) * SHA-3 (including SHAKE XOFs) and BLAKE2 hash algorithms * Salsa20 and ChaCha20 stream ciphers * scrypt and HKDF * Deterministic (EC)DSA * Password-protected PKCS#8 key containers * Shamir’s Secret Sharing scheme * Random numbers get sourced directly from the OS (and not from a CSPRNG in userspace) * Cleaner RSA and DSA key generation (largely based on FIPS 186-4) * Major clean ups and simplification of the code base PyCryptodome is not a wrapper to a separate C library like OpenSSL. To the largest possible extent, algorithms are implemented in pure Python. Only the pieces that are extremely critical to performance (e.g. block ciphers) are implemented as C extensions. Fedora Account System Username: ignatenkobrain
Blocking legal tracker as I'm not completely sure that we can have OCB (but looks like we have OCB in libtomcrypt, mosh. Though we strip it out from OpenSSL. So it's better to be sure. My thoughts written in spec file: # Only OCB blockcipher mode is patented, but according to # http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf # BSD 2-claus ("Simplified") has been approved in 2009 so # it means license for OSS Implementations applies here. Related thread at mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/PPJTMAQITOAHHTAYXEWWMX6NHPLUZDFL/#PPJTMAQITOAHHTAYXEWWMX6NHPLUZDFL
You can have OCB. Lifting FE-Legal.
Taking this review.
Could you please update the package to the latest version? Since you're doing patching and other things to it, I'd like to see this bumped to 3.4.3 first.
Spec URL: https://ignatenkobrain.fedorapeople.org/for-review/python-pycryptodome.spec SRPM URL: https://ignatenkobrain.fedorapeople.org/for-review/python-pycryptodome-3.4.3-1.fc26.src.rpm
There were a few concerning issues spotted: python2-pycryptodomex.x86_64: W: pem-certificate /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/PublicKey/test_vectors/ECC/ecc_p256_x509.pem python2-pycryptodomex.x86_64: E: non-executable-script /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/PublicKey/test_vectors/ECC/gen_ecc_p256.sh 644 /bin/sh python2-pycryptodomex.x86_64: E: wrong-script-interpreter /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/__main__.py /usr/bin/env python python2-pycryptodomex.x86_64: E: non-executable-script /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/__main__.py 644 /usr/bin/env python python2-pycryptodomex.x86_64: E: backup-file-in-package /usr/share/licenses/python2-pycryptodomex/LEGAL/copy/LICENSE.orig python3-pycryptodomex.x86_64: W: pem-certificate /usr/lib64/python3.6/site-packages/Cryptodome/SelfTest/PublicKey/test_vectors/ECC/ecc_p256_x509.pem python3-pycryptodomex.x86_64: E: non-executable-script /usr/lib64/python3.6/site-packages/Cryptodome/SelfTest/PublicKey/test_vectors/ECC/gen_ecc_p256.sh 644 /bin/sh python3-pycryptodomex.x86_64: E: wrong-script-interpreter /usr/lib64/python3.6/site-packages/Cryptodome/SelfTest/__main__.py /usr/bin/env python python3-pycryptodomex.x86_64: E: non-executable-script /usr/lib64/python3.6/site-packages/Cryptodome/SelfTest/__main__.py 644 /usr/bin/env python python3-pycryptodomex.x86_64: E: backup-file-in-package /usr/share/licenses/python3-pycryptodomex/LEGAL/copy/LICENSE.orig Also, do you really need to add an "x" to the name of the package in the metadata? We don't have a pycryptodome module, and the package is already in the filesystem as pycryptodome, which is different from pycrypto.
(In reply to Neal Gompa from comment #6) > There were a few concerning issues spotted: > > python2-pycryptodomex.x86_64: W: pem-certificate > /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/PublicKey/ > test_vectors/ECC/ecc_p256_x509.pem don't think that it's problem > python2-pycryptodomex.x86_64: E: non-executable-script > /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/PublicKey/ > test_vectors/ECC/gen_ecc_p256.sh 644 /bin/sh easy to fix > python2-pycryptodomex.x86_64: E: wrong-script-interpreter > /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/__main__.py > /usr/bin/env python easy to fix > python2-pycryptodomex.x86_64: E: non-executable-script > /usr/lib64/python2.7/site-packages/Cryptodome/SelfTest/__main__.py 644 > /usr/bin/env python easy to fix > python2-pycryptodomex.x86_64: E: backup-file-in-package > /usr/share/licenses/python2-pycryptodomex/LEGAL/copy/LICENSE.orig not a bug > > Also, do you really need to add an "x" to the name of the package in the > metadata? We don't have a pycryptodome module, and the package is already in > the filesystem as pycryptodome, which is different from pycrypto. Well, not sure. I just named it same as egg name...
You have this logic in your spec: >%global nsname %{srcname}x ># For now we don't want to replace PyCrypto as it requires patching of ># libraries/applications (in some cases). >%global eggname %{nsname} ... ># Use separate namespace >touch .separate_namespace Which looks like it triggers the usage of the "cryptodomex" name. It looks like when you don't have that, it uses "Crypto" namespace? I guess it's fine, since the other option supported by upstream is to use "Crypto" namespace, which we don't want right now.
Hi! pycryptodome is needed by mycli 1.9.0[1][2], anything I can do to help to move this forward? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1433707 [2]: https://github.com/dbcli/mycli/blob/master/setup.py#L21
Igor, Are you still interested in getting this in? I hadn't seen any updated spec and SRPM with requested fixes.
Seems to have been done by someone else. *** This bug has been marked as a duplicate of bug 1552033 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days