Josh talks to Paul Kehrer and Alex Gaynor, from the Python Cryptographic Authority. Alex and Paul recently published a statement discuss the challenges posed by modern OpenSSL. We discuss the statement and their relationship with OpenSSL. We chat about some of the current features in cryptography, as well as some of what’s coming in the future. It’s a fun conversation that hits on a lot of great points.

This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.

Episode Transcript

Josh Bressers (00:00) Today, open source security talking to Paul Kehrer and Alex Gaynor the maintainers of the Python Cryptographic Authority. Paul and Alex were kind enough to join us. They wrote a blog post about OpenSSL that’s kind of taken the internet by storm. So I want to thank you both for being here. And since Paul is the leftmost on my screen, I’ll say, Paul, why don’t you kind of introduce yourself? And then we’ll go to Alex and we’ll go from there.

Paul (00:23) Absolutely. So as you already said, I’m Paul Kehrer and I’m one of the co-maintainers of the Python Cryptographic Authority. Our principal library is kind of the de facto standard Python cryptographic library. And in a feat of hubris back in 2013, when we first started this project, we named it cryptography, thus ensuring that no one could ever Google for it. It’s maintained, like I maintain this in my spare time along with a few other libraries and it’s kind of a passion project.

Yeah, and I guess that’s about it. I’ll pass it to you, Alex.

Alex Gaynor (00:56) Yeah, along with Paul, I’m the other principal maintainer of the Python cryptographic authority. Paul and I maintain this in our spare time, so we’re not speaking on behalf of our employers here. Yeah.

Josh Bressers (01:10) Okay, so let’s just start out by first saying what is, I’m just gonna call it cryptography, because that’s what I have in my brain, since that’s what it, what is cryptography? Like, what does it do and why would anyone use it?

Alex Gaynor (01:25) Yeah, so cryptography is a Python library that provides access to cryptographic algorithms like RSA or AES, as well as file formats that are widely used in cryptographic ecosystems, things like X.509 certificates. ⁓ So you’d pretty much use this if you’re doing almost anything cryptography in Python, with the exception of TLS, which we actually don’t have APIs for.

So if you’re encrypting things, you’re signing things, issuing certificates, anything like that, ⁓ you’re likely to use us. The Let’s Encrypt Command Line tool uses us, Certbot. Lots of tools like that use us.

Josh Bressers (02:06) Cool, right on. And we’ll start with your blog post and go from there. But I don’t know, is it a blog post? It’s in a statement, it says on your website, so.

Paul (02:18) Yeah, so the Python Cryptographic Authority has never written a blog post before and we don’t really want to operate a blog. And accordingly, we’ve had this conversation kind of going in the background for quite a number of years. We know a bunch of the OpenSSL maintainers, they invited us to talk at their conference where we gave the visual and audio form of this statement. But ⁓ as we…

Josh Bressers (02:22) Okay.

Fair enough.

Paul (02:45) wanted to move on and figure out what it looked like to have a broader audience for the concerns that we have around this. We thought we need a venue to publish it. Alex and I talked a little bit about whether it belonged on our personal blogs and we decided, no, it has a lot more power as a joint statement coming straight from the project itself. So we had to create a new section on our documentation website.

Josh Bressers (03:07) And I will add, this is the only statement that you have on your documentation website. Okay, so the title here, it says the state of OpenSSL for PyCA slash cryptography. And I will let the two of you explain this statement because I feel like it’s relatively powerful. And I think you hit on a lot of things that a lot of people in the industry have kind of been.

Paul (03:12) That is correct.

Alex Gaynor (03:13) you

Josh Bressers (03:35) know, whinging about for years and decades, honestly, about OpenSSL. So I let the two of you argue over who starts and go from there.

Paul (03:44) Sure. So Alex, think what I’ll do is I’ll start with a quick recap of why we consume it and why we care. And Alex can kind of move into the set of concerns that we have around this. So when the Python cryptography project was started, we very consciously made a decision that we did not want to be implementing cryptography ourselves. Now, there’s a lot of nuance around what is and is not cryptography and those boundaries have become more fluid for us over time, especially as Alex and I, whether or not we want to admit it or not.

are largely cryptographic engineers in these days. ⁓ However, OpenSSL was and remains the de facto standard across the industry for open source cryptography. It provides FIPS compliance environments where you need it and it’s installed by default effectively in every distribution and including even in macOS at the time when we were shipping. ⁓ Accordingly, we based ourselves on top of it. ⁓ When we started, we actually supported all the way back to OpenSSL 098.

And then we moved and we were running through 098 through 101 and then we moved into 102, 110, 111 and then moved into the OpenSSL three betas and alphas where many of our largest concerns began. So from there, I’ll actually pass it over to Alex and we can talk a little bit about what that, what those concerns actually look like.

Alex Gaynor (05:01) Yeah, as Paul said, maybe the way I’ll contextualize this is I think many people’s negative experience with OpenSSL date to the Heartbleed era back in 2014. But for us, many years post-Heartbleed, OpenSSL got better. OpenSSL got new resource in which it used to improve testing, add important missing APIs. And then OpenSSL started the OpenSSL 3.0 process, which was really a big rethinking of their

Josh Bressers (05:12) Yeah.

Alex Gaynor (05:30) internals as well as their public APIs. And for us, OpenSSL 3 became like a quite negative experience in a couple different dimensions. So what we found is the public APIs got a lot more complex, a lot less ergonomic, a lot harder to use. The internals of OpenSSL became much more difficult to trace and read. I think many people who are advanced consumers of libraries they use will probably have the experience of, you

Sometimes I just have to read the source and not just the documentation to know how it works. And we found the just go to the source became a lot more challenging with OpenSL 3. ⁓ And OpenSL 3 also significantly regressed performance. Many important operations you might do like parsing a key became a lot slower. And ⁓ at the same time, it didn’t make progress on things we think are really important.

improving the state of testing and formal verification of OpenSSL, or ⁓ making ⁓ progress on stronger approaches to memory safety in OpenSSL. So for these set of reasons, we’ve had growing levels of concern about OpenSSL 3, ⁓ particularly how good a fit OpenSSL 3’s development direction was for our library.

And we found there’s just like increasing divergence from between what we want in a cryptography library in the directions OpenSSL is taking.

Josh Bressers (07:01) sure.

Paul (07:01) Yeah.

And one thing before we move on, I just want to quickly note, Alex mentioned performance. And one of the things that we found in the wake of publishing this statement is that ⁓ various groups have, I think, over-indexed on our performance concerns. Performance is, of course, important. But that is not the primary criticism we have. That is just a result of the complexity and other things that we have seen occur over time.

Josh Bressers (07:25) Right, for sure. And I know that is, you are not the only group of people I’ve heard complain about the performance of OpenSSL 3. think it was Daniel Stenberg, the curl maintainer, way back in the day was complaining about how much slower it is. So anyway, and I want to also bring up one of the things you note in your document here.

Like OpenSSL isn’t the only game in town anymore, know back in 2013 when when you folks started this It probably was I don’t think cuz really the forks came after heartbleed if I recall correctly now Yeah, yeah. So like let’s talk about some of the like what other things are there out there, right? Because you’d like you can like if you wanted to it hurt But you could move off of OpenSSL at this point in time. Whereas when you started that was not a realistic scenario

Paul (08:05) That’s correct.

Alex Gaynor (08:21) Yeah, that’s right. I mean, the time we started, there just was only OpenSSL. There were no forks. And I will say, originally when the forks started, we did not want to maintain support for them. That felt like a lot of extra work for not a lot of benefit. But over the years, we have added support for LibreSSL, BoringSSL, and AWS LC to the point where if you want to bring your own of any of those, we will work with any of them. ⁓

And I guess just terms of the state of them, we think those are all pretty good libraries. They all have, I guess, pretty different philosophies across many axes. LibreSSL, I would say, is ⁓ much less performance-oriented. They’re less likely to have the specialized assembly for the latest Intel CPU or something like that. ⁓ BoringSSL is very clear. They do not commit to any ⁓

API stability for anyone who is not Google, right? Like, you may look, you may not touch or something, but we think it’s like a really high quality library, notwithstanding that. And AWS LC is actually a fork of boring SSL, but they have committed much more strongly to, they intend this to be a widely consumable library. Yeah, I don’t know what else you’d say about them, Paul.

Josh Bressers (09:23) Right. Right.

Paul (09:44) I mean, the only other thing I would say is that each one has taken somewhat different approaches to the API surface area that it chooses to expose. you have, you obviously have a very, they all diverge roughly at the same time, which is to say they have an OpenSSL 1.02 slash 1.1.1 style API. At this time, none of the forks have adopted OpenSSL 3 APIs, although there are some small steps towards.

⁓ at least some pieces of that for some of the forks at this point. And then some of them have significantly diverging APIs, especially in the realm of things like post quantum cryptography. So MLCam and MLDSA are areas where we may have permanent diversions.

Josh Bressers (10:30) Yeah, and the other thing that I think is really cool is it’s Amazon and is it Boring? I can’t remember the other one, but two of them have formal verifications of their crypto code, is… Boring does, okay.

Paul (10:43) AWS LC and Boring both have formal verification

for subcomponents. So Boring has Fiat crypto for ⁓ basically the field arithmetic and elliptic curves. And then I don’t actually recall exactly what AWS LC has, but they have some formal verification in quite a few places.

Josh Bressers (10:59) which you do correct me if I’m wrong, because my understanding is a formal verification is, you think of it as like a mathematical proof where they have proved that the code is correct and it actually does what it’s supposed to do versus kind of a lot of computer code, which is, we think it does what it’s supposed to do. It passed the test, it’s probably fine, right?

Alex Gaynor (11:22) Yeah, I mean, that’s basically right. There’s several different approaches to how people do formal verification. The Fiat Crypto, ⁓ Paul mentioned, actually works by you write your field arithmetic in a specialized language, and then it generates C code from the formally verified stuff. It’s kind of like its own compiler, as opposed to attempting to directly formally verify your C code or something like that. yeah.

Paul (11:50) Yeah, an AWS LC has, I think they have a mixture, but like certainly one of the AWS has had a relatively heavy approach, especially in S2N, which is their TLS library, around having code and having formal verification language and attempting to make sure those things stay in sync, which is a challenging thing of its own, where sometimes the proof does not actually match the implementation. like Alex and I have something of a bias towards things that can generate things from the formal verified.

Josh Bressers (12:10) Yeah.

Paul (12:19) the formerly verified language. But that is actually a challenging and active area of research that folks like the high assurance crypto seminar, like HACS spend a lot of time thinking about how they can do better at that.

Josh Bressers (12:32) That’s fair. And that’s like a whole, it’s beyond my realm of understanding, but I find it fascinating. I know I talked to the, the, the rust TLS folks on the show a couple of months ago. And that’s one of the things they mentioned is they’re using the formally verified libraries from Amazon in their project, which is super cool. I mean, I love hearing about that kind of stuff. So, okay. Before we kind of dig into some of this, I want to say, I want to ask, so you said you were at the.

the OpenSSL conference, was in, it was in Prague, if I’m remembering correctly. I had them on the show actually, right before their conference, and they were talking about it. And how did they take this feedback? Because I know one of the things like we discussed was their desire to kind of, you know, talk to the community and understand what people are saying, because like the OpenSSL project will not…

Paul (13:04) Correct.

Josh Bressers (13:23) They recognize like they have many sins in their past and they’re very good about that. Like I feel like they have a very good attitude, but I’m curious how this particular these were these were all taken.

Paul (13:33) So we were directly invited ⁓ by the OpenSSL Foundation for this talk. We’re significant consumers of theirs, they’re aware of it. We actually exist inside their CI as a component of their regression testing suite. Although some of the things that they’ve regression test are things we’ve been reducing our own surface area dependence on OpenSSL on for quite some time. ⁓ But ⁓ Matt Caswell the president of the foundation, ⁓ was very receptive.

Josh Bressers (13:37) Nice.

Nice.

Paul (13:59) I want to make sure that we’re very clear that the OpenSSL folks have actually been extremely polite in all forms. They invited us directly into their home. We told them it would be a critical talk. They welcomed the critical talk. When we provided the talk, we had multiple OpenSSL developers in the room and there was no ill will. But our concerns around this are such that while the project does acknowledge its faults, it acknowledges the challenges it has, it acknowledges its history.

Acknowledging it is not an excuse for not changing behavior in the future.

Josh Bressers (14:34) And it should also be mentioned, you too are functionally volunteers here. You’re not being paid to put up with this crap, right? Like you’re doing this in your free time. So there’s also something to be said about using libraries that will say respect the time of the people using them, right?

Alex Gaynor (14:55) Yeah, think it’s definitely right. Paul and I both work on cryptography in our free time. I think kind of the we, maybe the shortest way of saying it is like, you know, if you have like a professional security team, like you think about like shifting left to like maximize developer productivity, right? Like you don’t want surprises in production or things like that. we don’t want, you know, we want all of our development to be like on our schedule. like, you know, bad experiences or like…

Josh Bressers (15:14) Yeah.

Alex Gaynor (15:22) You need to respond to vulnerabilities or API changes or all like, you know, things you want to like avoid in your hobby.

Josh Bressers (15:29) Yeah, that’s fair. That’s fair. Okay, so I’m looking at your piece here and you start out with performance, which we kind of talked about. You talk about complexity in APIs, which we touched on a little bit, but you have a section called testing and verification. And this is the one of the things I wanted to talk to you two about because I actually don’t really know. I know very little about what you’re doing in your CI environment. And there’s somewhere in here, you started at the beginning. We have a joke that the Python cryptographic authorities, a CI engineering project.

And so like explain what that means to anyone listening who might not understand.

Alex Gaynor (16:03) Yeah, mean, it means we spend a lot of time polishing our continuous integration environment. ⁓ Paul and I will meet at PyCon most years, and we’ll work on cryptography together there. And for several years in a row, all we did, more or less, was revamp and improve our continuous integration. And our theory there is, if our continuous integration is great, any time we’re spending on the library, we’ll be time well spent.

We’ll have really high confidence in what we’re shipping. We won’t have regressions. We’ll catch bugs or performance issues very early. no surprises. ⁓ No surprises later. We issue a release, and people show up saying, why is it broken? Well, we get that sometimes. But it’s for things that were intentional, ⁓ never by accident, more or less. ⁓ And so we think it’s really important to shipping.

High quality software. Cryptography is in many ways more testable than many other things you could do. We have large volumes of ⁓ known answer tests where you run the encryption, you run the decryption, and you check the results. Getting to something like 100 % coverage on your code is very straightforward. There are challenging areas like constant time testing. But in the main, testing that something is correct.

at least is like a quite tractable thing, we think.

Josh Bressers (17:34) Right on. And I feel like cryptography is one of those places, like when you make mistakes, it goes sideways really fast, right?

Paul (17:46) That’s true. It’s also the case that a lot of the time, the difference between cryptography that works and cryptography that doesn’t is invisible, right? Like a broken encryption that round trips correctly looks the same to a developer as one that does work correctly. And so it’s very important that the APIs ⁓ are both designed in ways that minimize the ability to shoot yourself in the foot and also that the underlying primitive is simply work the way you expect regardless of…

Josh Bressers (17:59) That’s very true.

Paul (18:11) the platform or the Indianness or whatever CPU architecture you might be operating on within the bounds of what we consider supportable, which is largely the set of architectures that have LLVM ported to them.

Josh Bressers (18:23) That’s a good point because I know I’ve done a lot of security work and I’ve dealt with a lot of security vulnerabilities. And more than once we’ve seen instances where developers like thought they were setting the key and they weren’t, or they had no initialization vector or whatever. And yeah, they were like for years, the application had functionally no cryptog encryption on the, over the network. And like literally no one knew cause the people who could figure this out, they know there’s six of them on the planet. They never looked, which I get.

Paul (18:52) Yeah,

and the language also can cause you challenges there. For example, if you were to do this startup work in C, you’re going to set up a byte array. And if you forget to populate that byte array, well, then it’s going to be either garbage or maybe it’s been null initialized. But either way, there’s some bytes there, and it’s going to use them. And so you will get no errors. It will process.

Josh Bressers (19:13) Yes.

Alex Gaynor (19:15) Yeah, and I would say particularly as you kind of go up the cryptography stack, above your core AES implementation, you’ve got all of these file formats, things like x.509 or PKCS7. And those are extremely testable. If you were just teaching a class on good testing, you might use these because they’re the perfect examples.

of like, it’s a self-contained file format. It’s well-documented. You can know exactly how it should work. So those are just things that there’s no reason not to be tested super well.

Josh Bressers (19:51) Well, you say that, but parsing X509 is difficult and has been fraught with problems throughout history. And you do actually, in your blog, sorry statement, you specify that you now have a pure rust parser for X509, which is super cool because now you can’t have buffer overflows in your X509 parsing.

Alex Gaynor (20:16) Yeah, I mean, yeah, we get no buffer overflows. also, I mean, I don’t know how much we want to go into the stuff we’ve done with Rust. But one of the other big benefits we’ve got is Rust’s safety with respect to lifetimes makes it really easy for us to do things like every subcomponent of an x.509 certificate is just a pointer back into the original buffer. So you avoid all sorts of allocations and copying in order to

which gets you a bunch of performance. And it’s one of those things where you can absolutely have pointers into an original buffer in C There’s no question that’s technically possible. But we’re able to do that with a high degree of compile time safety, right? No risk of, ⁓ the pointer you got out of the subject accidentally outlived the original buffer. We just don’t have those risks, and we get the performance wins.

Josh Bressers (21:06) Yeah, yeah. mean, look, let’s talk about your Rust actually, because actually yesterday on the calendar, but sometime before this episode, I talked to Sylvestre who’s the author of the Rust core utils that are going into Ubuntu now by default. And, we talked about all like the magic things kind of Rust gives from a security perspective, but he like points out it’s not it’s not just about security necessarily, because like Rust is fun.

And also like it’s attracting a younger crowd, we’ll say, versus a lot of Cs. So yeah, I mean, tell us about your rust. Like, what are you doing? What do you want to do with it? You know, what’s kind of the, what, give us the down low.

Paul (21:44) So back in 2020, I guess it was probably mid 2020, right Alex? I think that’s when we started really seriously pursuing what does it look like for us to increasingly oxidize our project. So at the time, PyO3, which is the Python Rust bindings already existed and was a very good project. David over there did and continues to do fantastic work. But like…

Josh Bressers (21:53) Wow.

Paul (22:11) it had never shipped in a really high profile project, which meant that there was a lot of questions about what does it mean? are the adoption costs? Python has both source distributions and binary wheels. Wheels are the binary distribution artifacts that you can produce. A lot of that in 2020, 2021 was not as mature as it is today. so Alex and I went down this path. We decided that this was worth it from both the security and developer ergonomics perspective, and that we were going to figure out what it meant to kind of…

eat the pain is the terminology we use. Like we would eat the pain as a project. We would figure out what the blockers were. We would go and like move the ecosystem forward such that we could keep doing this and also that we could unblock other projects in the future so they can more fearlessly make this migration. So we notified folks of our intent in late 2020 and then we shipped our first release which had a Rust component that did nothing. So you could actually compile back.

You could compile it back out if you didn’t want it in February of 2021. And there were a variety of things that came out of that. was a few, I think there was one relatively heated GitHub thread, but other than that, it was generally pretty good. And we moved forward and we fixed a variety of things. And frankly, the ecosystem stepped up and did a bunch of work too. Like at the time there was no mechanism of shipping wheels on musl Linux, which is of course important for Alpine. And that was resolved. And there was a variety of other areas where like,

the compilers weren’t quite in the shape we needed them to be, or they weren’t bootstrapped inside of the Linux distro. And all that stuff actually changed over the course of a few years, including what Alex and I consider are perhaps undeservedly, but we still consider it one of our crowning achievements, which is that IBM shipped Rust on AIX. And one of their headline statements in that shipment was that you could compile cryptography.

Josh Bressers (24:04) Nice, nice. Okay, so let me ask a technical question then. So like you wrote an X.509 parser in Rust, like why not just make it like pure Python?

Alex Gaynor (24:15) Yeah, mean, the biggest reason to not do x.509 or any of other stuff we’ve done in Rust in pure Python is ⁓ performance. If Python is not a particularly fast language, I used to be a Python performance person. I worked on ⁓ PyPy and Unladen Swallow before that. I would love for it to be possible to just write high performance Python, but like,

Josh Bressers (24:31) Yeah, yeah.

Alex Gaynor (24:43) That’s not the case today. You’d be giving up probably at least 10x performance. honestly, could be worse. It wouldn’t surprise me if it was worse. ⁓ And I think one of my beliefs is for better or for worse, lots of organizations, cryptography is a thing they add on after the fact. They design some system, they’re like, now we got to add the security after we’ve already built it.

Josh Bressers (24:50) Whoa, that bad.

Yup, yup.

Alex Gaynor (25:12) That is unfortunate. I would like to not live in that world. I’d like security to be a consideration from day one. But it’s not. I don’t have the tools to make that be the case. And so as a result, it’s really important that when people go to add the cryptography, it doesn’t make whatever they’re building so much slower that they’re like, ⁓ maybe I should skip this. So we think cryptography needs to be fast, primarily so that it is never the r-

Josh Bressers (25:36) Sure.

Alex Gaynor (25:42) Performance is never the reason somebody shouldn’t encrypt something or sign something or, you know, whatever.

Paul (25:48) I would say, I would also note on that one, that like per the conversation earlier around us ⁓ doing this, cause it’s fun is that the, rust side of this sling of this work is a lot of fun. Like we get to play, we get to play with really high performance things. get to like go and say, well, how can I design this in a manner where we can ensure that it never, never does any allocations. And like, obviously in the Python world, part of the reason why you get that 10 X or worse slowdown is

Josh Bressers (25:58) Yeah. Yeah.

Paul (26:13) there’s going to be an awful lot of allocations inside of the slab allocation that Python itself is using. But like everything’s an object. There’s lots and lots of other overhead components. Every time you allocate an object itself, you’re going to have like a dictionary that gets allocated. There’s just so many things and it’s much easier to reason about like, here’s how this is going to work. And this is like the exact memory layout that we’re going to expect when we allocate this struct in Rust.

Alex Gaynor (26:37) Yeah, and I would say we can do that performance work in very idiomatic rust, whereas people who attempt to do high performance truly in Python, not with something like NumPy or something like that, high performance looks like less idiomatic Python. it’s also, by using a language designed for performance, we don’t have to take that trade off between idiomaticness and performance.

Yeah, sure. For things that are even more cryptography, things like we have un-padding done in Rust for ⁓ symmetric encryption, message padding. There’s no way to do that in constant time in Python. It simply has to be in a language that affords you more control. That’s it.

Josh Bressers (27:23) Yeah. Yup. Yup. For sure.

Okay. So, so I want to kind of land this plane asking what’s next because I’m curious, like has, has OpenSSL done any, taken any steps to address some of, know, the issues you’re talking about? I know you mentioned in your statement about potentially dropping OpenSSL in favor of one of the, forks we talked about. I’m, I’m curious, like,

what’s going on now, because it’s been basically almost a month since you wrote this. So I’m curious what’s happened since then.

Alex Gaynor (27:57) Yeah, so we know ⁓ many of the OpenSSL developers have been discussing ⁓ the issues we raised on forums ⁓ we’ll let them just speak to what they’re thinking in terms of their direction. But for us, we laid out a couple of next steps for us. And the immediate term one is, historically, unwritten policy is we don’t ship functionality that doesn’t work on OpenSSL.

Everything’s got to be there. Might not necessarily be on all the forks, but got to be an OpenSSL at least. And we’re going to pull back on that policy. And in our next release, we’re hoping to ship post-quantum cryptography, probably MLChem and MLDSA. And the implementations there will be probably for the forks only, or maybe a subset of the forks. We haven’t figured out the exact details, but we’re not going to try to do OpenSSL first for those. We’re going to figure out our APIs and testing and documentation. We’ll do all those.

Josh Bressers (28:36) Nice.

Alex Gaynor (28:54) For the forks first, that’ll be what’s in the release, and we’ll see if OpenSSL comes afterwards. But we found that having OpenSSL be the blocker to doing these is just exposing us to lot of the API frustrations we talked about at the top. So that’s the immediate term. Yeah.

Josh Bressers (29:12) So can I ask a quick clarification

on that? So if you’re going to support the post-quantum crypto, are you going to also ship the forks in the wheel or are you going to still ship OpenSSL in the wheel?

Alex Gaynor (29:25) Yeah, we’re going to still ship OpenSSL on the wheel, which is going to be this very awkward thing that many of our users will not have access to ⁓ the new functionality. We’re conscious. We’re not wild about that, but that’s balancing the backwards compatibility impact and trying to make forward progress. This is the next step. yeah, the next step after that is figure out what would it take to migrate our wheels. And there, the big question is the wheels all have

Josh Bressers (29:32) Gotcha.

Alex Gaynor (29:52) different subsets of OpenSSL’s functionality and figuring out what are we comfortable dropping? What can we maybe encourage one of the forks to add? How do we minimize ⁓ the ⁓ potential features we’re giving up by switching to a fork?

Paul (30:09) Yeah. And the timelines for that start getting longer than Alex and I would like, but probably shorter than many of our consumers would prefer. ⁓ So like the goal here is not necessarily, you know, if OpenSSL doesn’t, you know, bow to our demands and the ways they need to change the direction of the project that we’re going to be gone in six months. Like this, this is a multi-year effort. ⁓ like OpenSSL, we recognize that OpenSSL as a project has, it takes a while to turn a ship.

And so if they choose to turn it, like we are ready and willing to stay on it if it makes sense. ⁓ If it does not, then like we are taking steps to protect ourselves and our users in the medium to long-term future.

Josh Bressers (30:52) Right, right. And I mean, we should also just note like cryptography is not the only OpenSSL user. Like they have an army of users, you know, beyond the gates that they’re and all of them have complaints, right?

Paul (31:06) Yeah, mean, OpenSSL is in many ways in, they are probably the most widely used cryptography library in the world. ⁓ And yes, it’s absolutely, they have a multitude of users, all of whom have ridiculous, like sometimes mutually exclusive requirements in the way they need to operate. It is genuinely a challenging project to move forward in a meaningful fashion. ⁓ The challenge we have of course, is that like they did move the needle.

Josh Bressers (31:14) Yeah.

Paul (31:32) And they spent a lot of time and energy changing things, breaking their ABI, moving it to a new model. And unfortunately, we think that new model is actually substantially worse.

Josh Bressers (31:41) Right on. Yeah. Yeah. I, for what it’s worth, I don’t know anyone who likes OpenSSL three. Like that’s just in my experience. feel like whatever, whatever they think they did to make it better. lot of users do not agree, which is fine. Their project, they’re allowed to do it, but. Okay. All right. I will let the two of you bring us home. So let us know if there is.

Anything you want us to know, if maybe anyone’s interested in the project and they want to learn more, you know, getting involved, using it, getting started, kind of whatever. I’ll give both of you the floor to end the show.

Paul (32:22) Sure. So ⁓ this project is hosted at github.com slash pyca slash cryptography. We’re always welcome. All users are welcome to come and file issues or ⁓ bring pull requests and things of that nature. We host our documentation at cryptography.io where you can see our statement as long as along with all the docs and the ways in which we develop the project. And I guess the last thing I’ll mention before I hand it over to Alex is that like it is our sincere hope that the OpenSSL project will adopt many of the things we’re talking about.

And one of the things that can help that happen is folks like those listening to this podcast going in very respectfully, getting involved with OpenSSL. Like the purpose here is not harassment. The purpose here is not to tell them that they’re doing anything wrong. That is not an effective means of advocacy in any open source project. And it’s offensive, frankly, the thing to do if you want to get involved and affect positive change is to come and bring your, your, your ethos, your opinions and your effort.

Josh Bressers (32:59) Yes.

Alex Gaynor (33:22) Yeah, I don’t have ⁓ terribly much ⁓ to add on top of that. We’re always enthusiastic for new contributors, ⁓ both to our library itself, but also to other good projects in the cryptographic ecosystem. you’re interested in cryptography standardization, for example, the Community Cryptographic Standards Project is a great place to contribute to improve the quality of testing for the entire cryptographic ecosystem. ⁓

maintain and support a library called x509-limbo, which is like a set of test vectors for x509 path validation. like, know, we’re loving it if folks want to contribute to us, but also like there are many kind of, you know, libraries and test frameworks we consume that we’re also enthusiastic for people to contribute to.

Josh Bressers (34:12) Right on. All right. All right. And I will put links to all this stuff in the show notes for anyone interested. Just go to the show notes and they’ll all be there. So, all right, Paul and Alex, this has been a fantastic discussion. I want to thank you both for the time. I truly appreciate it.

Alex Gaynor (34:26) Thanks so much for having us.

Paul (34:26) Thanks for having us, Josh.