We're definitely aware that there are a variety of consumers that aren't visible in the limited metrics available to us. Maintaining the status quo is always the "best" path in the short term for our users, as it removes the need to make alterations of any kind. However, that stance is incompatible with moving the broader ecosystem towards better solutions, so the reality is that we need to balance our desire to have a maintainable system and improve the project with myriad other needs. As a packager of our project I would expect, when encountering news of a change in the build system, that you would clone the current repository, experiment with it in your environment, and let us know if there's some issue beyond simple problems like needing to install a compatible rustc. Thus far it's unclear to me what action you want this project to take in response to your statements in this thread.
We believe incorporating Rust into cryptography is in the best long-term interest of the project for users and developers. For example, we can provide high performance memory safe implementations of parsers through our Rust bindings and we'll be able to implement support for some things that were previously not practical (arbitrary ASN.1 parsing is extremely unpleasant in OpenSSL). We have no intention of replacing OpenSSL itself, as it provides a variety of advantages (especially in the realm of compliance) to our users, but Rust code will augment the core over time. To minimize the pain on the subset of users that need to compile cryptography themselves we have announced this in multiple venues and have developed a plan to ensure minimal impact. We recognize that there's no truly effective means of communication with all of our users other than shipping code, so our upcoming 3.4 release allows you to entirely disable the Rust requirement *without affecting functionality in any way*. This allows packagers who haven't seen our previous announcements additional time to determine the best way to properly support a hard Rust dependency. If you have additional suggestions on how we can more effectively communicate this transition we would be happy to discuss them. The only hard statement is that we do not intend to turn back from this path because we believe it would be irresponsible to do so. A safe library must attempt to use memory safe languages where feasible, and performance is a critical feature to many of our users. -Paul Kehrer (reaperhulk) On Wed, Jan 13, 2021 at 8:51 AM Barry Scott <barry.sc...@forcepoint.com> wrote: > > On Wednesday, 13 January 2021 14:47:37 GMT Alex Gaynor wrote: > > I'm glad to hear some folks are actually auditing 3rd party sources. > > > > Once you install a rust toolchain, you'll be able to build > > pyca/cryptography the same as ever. > > > > To repeat: if there's some action we can be taking to make this > > migration smoother, we're happy to consider it. But what we won't do > > is simply stop trying to drop C. > > I'm all for better code. > > I just wanted to point out that you have user that do not show up in PyPI > stats. > > Barry > > > > > > Alex > > > > On Wed, Jan 13, 2021 at 9:45 AM Barry Scott <barry.sc...@forcepoint.com> > > wrote: > > > > > > On Tuesday, 12 January 2021 17:23:10 GMT Alex Gaynor wrote: > > > > Running `yum install rust` in a CentOS8 docker container seems to get > > > > me rustc 1.45.2, and as our docs say, 1.45.0 will be the initial > > > > minimum version > > > > (https://cryptography.io/en/latest/installation.html#rust). > > > > > > > > As ever, our wheels (which are how the vast majority of our users > > > > install pyca/cryptography) will not require any compiler or build > > > > toolchain on user's machines. > > > > > > But in the enterprise space its a no-no to use the wheels you build. > > > > > > I get your source, audit it and build that for use in our environment. > > > > > > Barry > > > > > > > > > > > Alex > > > > > > > > On Tue, Jan 12, 2021 at 12:17 PM Barry Scott > > > > <barry.sc...@forcepoint.com> wrote: > > > > > > > > > > On Tuesday, 12 January 2021 15:52:01 GMT Michael Ströder via > > > > > Cryptography-dev wrote: > > > > > > On 12/22/20 8:43 PM, Alex Gaynor wrote: > > > > > > > As we previewed in August [0] we're planning to incorporate Rust > > > > > > > code > > > > > > > into pyca/cryptography. > > > > > > > > > > > > IMHO this will make life of distro packagers more miserable > > > > > > especially > > > > > > on non-x86 platforms. > > > > > > > > > > I was also concerned by that new toolset dependency. > > > > > > > > > > Will this build on Centos 8 with the version of rust that is packaged > > > > > there? > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Cryptography-dev mailing list > > > > > Cryptography-dev@python.org > > > > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
