From niyas.sait at linaro.org Tue Nov 2 05:54:15 2021 From: niyas.sait at linaro.org (Niyas Sait) Date: Tue, 2 Nov 2021 09:54:15 +0000 Subject: [Cryptography-dev] wheels for win/arm64 platforms Message-ID: Hello, I have been looking at enabling cryptography python package for windows on arm64 targets. Luckily without much effort, I was able to compile OpenSSL and then the cryptography package, and all unit tests were completed successfully as well. I would like to explore how we would be able to test and produce win/arm64 binary wheels for cryptography on pypi repository. One of the main issues would be the lack of win/arm64 machines on the cloud. Considering we are already producing binary wheels for mac/arm64 without cloud support I think it probably doesn't have to be a blocker and we might be able to look into the same strategy for producing wheels for win/arm64. Can someone provide some insights on how we can add support for win/arm64 ? Thanks, Niyas -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Tue Nov 2 07:15:09 2021 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 2 Nov 2021 19:15:09 +0800 Subject: [Cryptography-dev] wheels for win/arm64 platforms In-Reply-To: References: Message-ID: Our current process for macOS arm64 involves me manually running a build script (which runs all our tests as part of the build). I don't want to expand that process; it is one of our biggest wishes that GitHub Actions ship arm64 macOS! We do use quite a bit of linaro resources at the moment through OpenDev -- are there any plans to enable win/arm64 CI through that vector? That said, we're generally going to be judicious about adding additional (platform, arch) tuples to our build systems until we have access to good (performant!) CI and have some demonstrated demand in the wild. A large CI system with all the potential flakiness that entails can be an albatross around the neck of a project, especially if many of those architectures have little real world use. -Paul -Paul On Tue, Nov 2, 2021 at 7:04 PM Niyas Sait wrote: > > Hello, > > I have been looking at enabling cryptography python package for windows on arm64 targets. Luckily without much effort, I was able to compile OpenSSL and then the cryptography package, and all unit tests were completed successfully as well. > > I would like to explore how we would be able to test and produce win/arm64 binary wheels for cryptography on pypi repository. > > One of the main issues would be the lack of win/arm64 machines on the cloud. Considering we are already producing binary wheels for mac/arm64 without cloud support I think it probably doesn't have to be a blocker and we might be able to look into the same strategy for producing wheels for win/arm64. > > Can someone provide some insights on how we can add support for win/arm64 ? > > Thanks, > Niyas > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev From a.n.gusakov at gmail.com Mon Nov 15 20:40:17 2021 From: a.n.gusakov at gmail.com (Andrey Gusakov) Date: Mon, 15 Nov 2021 17:40:17 -0800 Subject: [Cryptography-dev] Linux CPython 3.8 version for cffi, bcrypt and PyNaCl Message-ID: Hi guys, TL;DR I'm looking to have the -cp38-*linux* version of these packages in PyPI. As a part of building docker image, I need to install paramiko for Python 3.8. It results in building crypt, PyNaCl and cffi from sources. Every time I build it bloats build time from 10-13 secs to almost 3 minutes. I tried to figure out why it needs to be built from sources, and the reason seems to be there's no wheel for this combination of version and architecture in the pypi repository. The build process ends up with the following three versions, so I'd assume that (or manylinux version of them) is what I need: cffi-1.15.0-cp38-cp38-linux_x86_64.whl bcrypt-3.2.0-cp38-cp38-linux_x86_64.whl PyNaCl-1.4.0-cp38-cp38-linux_x86_64.whl So, would you mind adding them? I also assume that it will resurface every time there's a new version, since pip seems to prefer to build the latest version even if there's the wheel for the prior version (satisfying requirement). But I'm sure you know better how to deal with it. Thank you and let me know if you need more info or if there's a better approach to this. - Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Mon Nov 15 20:58:55 2021 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 15 Nov 2021 20:58:55 -0500 Subject: [Cryptography-dev] Linux CPython 3.8 version for cffi, bcrypt and PyNaCl In-Reply-To: References: Message-ID: Cryptography already publishes abi3 wheels that cover all supported versions of Python3: https://cryptography.io/en/latest/faq/#why-are-there-no-wheels-for-my-python3-x-version You likely need to upgrade your version of pip. Alex On Mon, Nov 15, 2021 at 8:57 PM Andrey Gusakov wrote: > > Hi guys, > > TL;DR I'm looking to have the -cp38-*linux* version of these packages in PyPI. > > As a part of building docker image, I need to install paramiko for Python 3.8. It results in building crypt, PyNaCl and cffi from sources. Every time I build it bloats build time from 10-13 secs to almost 3 minutes. I tried to figure out why it needs to be built from sources, and the reason seems to be there's no wheel for this combination of version and architecture in the pypi repository. > > The build process ends up with the following three versions, so I'd assume that (or manylinux version of them) is what I need: > > cffi-1.15.0-cp38-cp38-linux_x86_64.whl > bcrypt-3.2.0-cp38-cp38-linux_x86_64.whl > PyNaCl-1.4.0-cp38-cp38-linux_x86_64.whl > > So, would you mind adding them? > I also assume that it will resurface every time there's a new version, since pip seems to prefer to build the latest version even if there's the wheel for the prior version (satisfying requirement). But I'm sure you know better how to deal with it. > > Thank you and let me know if you need more info or if there's a better approach to this. > > - Andrey > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -- All that is necessary for evil to succeed is for good people to do nothing. From paul.l.kehrer at gmail.com Mon Nov 15 21:01:23 2021 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 16 Nov 2021 10:01:23 +0800 Subject: [Cryptography-dev] Linux CPython 3.8 version for cffi, bcrypt and PyNaCl In-Reply-To: References: Message-ID: Tags with "linux" are disallowed to PyPI because they will not be cross-compatible. The manylinux (and later musllinux) specifications were created to allow binary distribution on Linux and cryptography uploads wheels for many permutations of that. cffi has slightly different restrictions (it cannot ship abi3 wheels, unlike cryptography), but also ships manylinux wheels for many versions. The most likely scenario here is that you need to upgrade your version of pip to the latest so that it correctly detects and downloads wheels. However, if you are somehow on an unsupported platform, building will be your only option (although there you could do it as a staged build and cache the generated artifacts for reuse in your own pipelines). -Paul On Tue, Nov 16, 2021 at 9:57 AM Andrey Gusakov wrote: > > Hi guys, > > TL;DR I'm looking to have the -cp38-*linux* version of these packages in PyPI. > > As a part of building docker image, I need to install paramiko for Python 3.8. It results in building crypt, PyNaCl and cffi from sources. Every time I build it bloats build time from 10-13 secs to almost 3 minutes. I tried to figure out why it needs to be built from sources, and the reason seems to be there's no wheel for this combination of version and architecture in the pypi repository. > > The build process ends up with the following three versions, so I'd assume that (or manylinux version of them) is what I need: > > cffi-1.15.0-cp38-cp38-linux_x86_64.whl > bcrypt-3.2.0-cp38-cp38-linux_x86_64.whl > PyNaCl-1.4.0-cp38-cp38-linux_x86_64.whl > > So, would you mind adding them? > I also assume that it will resurface every time there's a new version, since pip seems to prefer to build the latest version even if there's the wheel for the prior version (satisfying requirement). But I'm sure you know better how to deal with it. > > Thank you and let me know if you need more info or if there's a better approach to this. > > - Andrey > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev From paul.l.kehrer at gmail.com Sun Nov 21 17:11:54 2021 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Mon, 22 Nov 2021 06:11:54 +0800 Subject: [Cryptography-dev] PyCA cryptography 36.0.0 released Message-ID: PyCA cryptography 36.0.0 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X509, key derivation functions, and much more. We support Python 3.6+, and PyPy3. (As a reminder, cryptography changed its versioning scheme with 35.0. For more information see https://cryptography.io/en/latest/api-stability/#versioning) Changelog (https://cryptography.io/en/latest/changelog/#v36-0-0): * FINAL DEPRECATION: Support for verifier and signer on our asymmetric key classes was deprecated in version 2.1. These functions had an extended deprecation due to usage, however the next version of cryptography will drop support. Users should migrate to sign and verify. * The entire X.509 layer is now written in Rust. This allows alternate asymmetric key implementations that can support cloud key management services or hardware security modules provided they implement the necessary interface (for example: EllipticCurvePrivateKey). * Deprecated the backend argument for all functions. * Added support for AESOCB3. * Added support for iterating over arbitrary request attributes. * Deprecated the get_attribute_for_oid method on CertificateSigningRequest in favor of get_attribute_for_oid() on the new Attributes object. * Fixed handling of PEM files to allow loading when certificate and key are in the same file. * Fixed parsing of CertificatePolicies extensions containing legacy BMPString values in their explicitText. * Allow parsing of negative serial numbers in certificates. Negative serial numbers are prohibited by RFC 5280 so a deprecation warning will be raised whenever they are encountered. A future version of cryptography will drop support for parsing them. * Added support for parsing PKCS12 files with friendly names for all certificates with load_pkcs12(), which will return an object of type PKCS12KeyAndCertificates. rfc4514_string() and related methods now have an optional attr_name_overrides parameter to supply custom OID to name mappings, which can be used to match vendor-specific extensions. * BACKWARDS INCOMPATIBLE: Reverted the nonstandard formatting of email address fields as E in rfc4514_string() methods from version 35.0. The previous behavior can be restored with: name.rfc4514_string({NameOID.EMAIL_ADDRESS: "E"}) * Allow X25519PublicKey and X448PublicKey to be used as public keys when parsing certificates or creating them with CertificateBuilder. These key types must be signed with a different signing algorithm as X25519 and X448 do not support signing. * Extension values can now be serialized to a DER byte string by calling public_bytes(). * Added experimental support for compiling against BoringSSL. As BoringSSL does not commit to a stable API, cryptography tests against the latest commit only. Please note that several features are not available when building against BoringSSL. * Parsing CertificateSigningRequest from DER and PEM now, for a limited time period, allows the Extension critical field to be incorrectly encoded. See the issue for complete details. This will be reverted in a future cryptography release. * When OCSPNonce are parsed and generated their value is now correctly wrapped in an ASN.1 OCTET STRING. This conforms to RFC 6960 but conflicts with the original behavior specified in RFC 2560. For a temporary period for backwards compatibility, we will also parse values that are encoded as specified in RFC 2560 but this behavior will be removed in a future release. -Paul Kehrer (reaperhulk)