4 ms·

Wow... reading this article in full really made me lose hope in OpenSSL, the project and the library. I was well aware of the expected inconveniences any new m

by c0l0 1y ago

Wow... reading this article in full really made me lose hope in OpenSSL, the project and the library. I was well aware of the expected inconveniences any new major OpenSSL release would trigger (esp. older, less actively maintained applications having to adapt their API usage to keep working) going in, but what the linked github issue/PR comments hint at is just... mental. As best illustrated by https://github.com/openssl/openssl/issues/20286#issuecomment-1547053752 https://github.com/openssl/openssl/issues/20286#issuecomment... not only seem the core developers not care about runtime performance at all, they also seem to have a completely absurd perception of their own project, esp. in relation to other, genuinely small FOSS projects. It's just wild. I hope this can still be turned around, and OpenSSL can somehow re-emerge from this clusterfuck as the stable bedrock of web transport security that we learned to rely on from 2014 onwards.

Hilift 1y ago
[flagged]
- wobfan 1y ago
  TIL that committing a bug disqualifies me from getting a PhD. Lucky that I stopped with my masters degree, that would’ve been a bad surprise
  - LtWorf 1y ago
    I hope there's no bugs in any of your projects or we might have to cancel your master's as well. Maybe even your high school diploma.
  - justinrubek 1y ago
    Well, at least you did a pretty good job of dismissing the point in the comment above you. Maybe that counts for something.
iforgotpassword 1y ago
I don't know how it happens but sometimes very old OSS projects turn into those bikeshedding projects completely disconnected from reality. It only serves the self-fulfillment of the developers. I've recently ranted about libgd here in another comment. Definitely not as bad, definitely not as mission critical as openssl, but same symptoms.
cryptonector 1y ago
That's two years ago and the issues have been fixed. Think of it this way: OpenSSL 3.0 was a release that added new, cleaner APIs and deprecated older, uglier APIs, so the focus was on that and not performance, but they've since put effort back into performance. And by the way: OpenSSL has always cared a great deal about the performance of their cryptographic primitives, but the issue you linked to is NOT about that but about a performance degradation that happened in the code that _loads_ and references cryptographic algorithms. IMO it's pretty lame to link to that issue as symptomatic of bigger problems in the OpenSSL community. And I say that as someone who was fairly involved in that issue as a user (I'm not an OpenSSL dev). It borders on the dishonest. How about giving them some accolades for responding to the issue, engaging the user community, and addressing the problem satisfactorily? And as for them not having all the hardware that users run on, the perf issue in question did not require any particular hardware. The issue was systemic and easily reproduced. Indeed, the OpenSSL devs ended up greatly improving how they do thread synchronization in general, because the issue was a combination of: a) using mutexes only, b) over time too many places got "get a reference to the cryptographic alg" calls that exacerbated all the problems with only using mutexes. So now OpenSSL has an RCU-like mechanism for thread synchronization that replaces mutexes for many read cases. That's _exactly_ the sort of large response program [to a systemic performance problem] that one would expect by an upstream that is well-funded and cares about performance. So really, OpenSSL issue #20286 is demonstrative of all the opposite of what you say! It demonstrates that OpenSSL - is well-funded, - has skilled developers, - is responsive to their users, and - is willing to make massive changes to their codebase. Show us how all of that is true of the others before you attack OpenSSL for having had a performance problem. BTW, it was I who proposed switching to RCU for these synchronization problems, and I half-expected to be told that that's not portable. Instead and after convincing them that the problem was quite real they jumped wholeheartedly into developing an RCU-ish solution. How often does it happen to you that you point out a serious architectural problem to a popular upstream and then they take it seriously and solve it as quickly as possible? I'm sure it's a rare occurrence. It sure is for me.
- rlnorthcutt 1y ago
  I have yet to find a perfect community anywhere - open source or not. And, as a general rule, I agree that we should try to support open source communities with whatever path they choose to take. In this case, it seems to me that OpenSSL has chosen to prioritize DX and broader accessibility over performance. Even as we have seen some performance improvements since the initial 3.0 release, it is still not where it was. Thats ok. As a widely used library, it may actually be a good idea for the project to prioritize the longtail of users over those who have the highest performance needs. This is a valid response. The only issue I see is that this may not have been clearly thought out or communicated, which is a completely understandable oversight. There is another potential issue with rolling out an LTS release that was not "fully baked" but again - these things happen. Overall, we should look to refine and understand the goals for the project, and be clear on the priorities of those leading and maintaining it.
stefan_ 1y ago
OpenSSL was always the library developed by clowns, the only upside is it was used by everyone (so a sort of "can't be fired for buying IBM" situation). Big problem for libraries like WolfSSL, which is equally made by people that have a crypto hobby but doesn't have the distribution.
jiggawatts 1y ago
> I'm not aware of any accessible hardware that goes beyond a small to, maybe at a stretch, moderate scale. As a small OpenSource project, we have to rely on the community to do this. That's especially absurd considering that it's possible to rent a VM in the public cloud with hundreds of CPU cores for the price of a cup of coffee per hour! I've seen several projects where their learned helpless transforms over years into an obstinate point of pride. For example, refusing to provide Windows builds in an era of free build pipelines in GitHub, virtual machines, cross-platform build tools, etc... "We don't do that here!" -- says person who could trivially do that.

by c0l0 1y ago

Hilift 1y ago

[flagged]

wobfan 1y ago
TIL that committing a bug disqualifies me from getting a PhD. Lucky that I stopped with my masters degree, that would’ve been a bad surprise
- LtWorf 1y ago
  I hope there's no bugs in any of your projects or we might have to cancel your master's as well. Maybe even your high school diploma.
- justinrubek 1y ago
  Well, at least you did a pretty good job of dismissing the point in the comment above you. Maybe that counts for something.

iforgotpassword 1y ago

I don't know how it happens but sometimes very old OSS projects turn into those bikeshedding projects completely disconnected from reality. It only serves the self-fulfillment of the developers. I've recently ranted about libgd here in another comment. Definitely not as bad, definitely not as mission critical as openssl, but same symptoms.

cryptonector 1y ago

That's two years ago and the issues have been fixed. Think of it this way: OpenSSL 3.0 was a release that added new, cleaner APIs and deprecated older, uglier APIs, so the focus was on that and not performance, but they've since put effort back into performance. And by the way: OpenSSL has always cared a great deal about the performance of their cryptographic primitives, but the issue you linked to is NOT about that but about a performance degradation that happened in the code that _loads_ and references cryptographic algorithms. IMO it's pretty lame to link to that issue as symptomatic of bigger problems in the OpenSSL community. And I say that as someone who was fairly involved in that issue as a user (I'm not an OpenSSL dev). It borders on the dishonest. How about giving them some accolades for responding to the issue, engaging the user community, and addressing the problem satisfactorily? And as for them not having all the hardware that users run on, the perf issue in question did not require any particular hardware. The issue was systemic and easily reproduced. Indeed, the OpenSSL devs ended up greatly improving how they do thread synchronization in general, because the issue was a combination of: a) using mutexes only, b) over time too many places got "get a reference to the cryptographic alg" calls that exacerbated all the problems with only using mutexes. So now OpenSSL has an RCU-like mechanism for thread synchronization that replaces mutexes for many read cases. That's _exactly_ the sort of large response program [to a systemic performance problem] that one would expect by an upstream that is well-funded and cares about performance. So really, OpenSSL issue #20286 is demonstrative of all the opposite of what you say! It demonstrates that OpenSSL - is well-funded, - has skilled developers, - is responsive to their users, and - is willing to make massive changes to their codebase. Show us how all of that is true of the others before you attack OpenSSL for having had a performance problem. BTW, it was I who proposed switching to RCU for these synchronization problems, and I half-expected to be told that that's not portable. Instead and after convincing them that the problem was quite real they jumped wholeheartedly into developing an RCU-ish solution. How often does it happen to you that you point out a serious architectural problem to a popular upstream and then they take it seriously and solve it as quickly as possible? I'm sure it's a rare occurrence. It sure is for me.

rlnorthcutt 1y ago
I have yet to find a perfect community anywhere - open source or not. And, as a general rule, I agree that we should try to support open source communities with whatever path they choose to take. In this case, it seems to me that OpenSSL has chosen to prioritize DX and broader accessibility over performance. Even as we have seen some performance improvements since the initial 3.0 release, it is still not where it was. Thats ok. As a widely used library, it may actually be a good idea for the project to prioritize the longtail of users over those who have the highest performance needs. This is a valid response. The only issue I see is that this may not have been clearly thought out or communicated, which is a completely understandable oversight. There is another potential issue with rolling out an LTS release that was not "fully baked" but again - these things happen. Overall, we should look to refine and understand the goals for the project, and be clear on the priorities of those leading and maintaining it.

stefan_ 1y ago

OpenSSL was always the library developed by clowns, the only upside is it was used by everyone (so a sort of "can't be fired for buying IBM" situation). Big problem for libraries like WolfSSL, which is equally made by people that have a crypto hobby but doesn't have the distribution.

jiggawatts 1y ago

> I'm not aware of any accessible hardware that goes beyond a small to, maybe at a stretch, moderate scale. As a small OpenSource project, we have to rely on the community to do this. That's especially absurd considering that it's possible to rent a VM in the public cloud with hundreds of CPU cores for the price of a cup of coffee per hour! I've seen several projects where their learned helpless transforms over years into an obstinate point of pride. For example, refusing to provide Windows builds in an era of free build pipelines in GitHub, virtual machines, cross-platform build tools, etc... "We don't do that here!" -- says person who could trivially do that.