@friesoft, @alexdotgov2, please try out this patch

Looks good to me on RHEL 7 + 8 + 9

Works for me on RHEL 7 + 8 + 9 :) Thanks for the lightning fast fix :)
Will this be released as a 3.3.2.1?

Works for me on RHEL 7 + 8 + 9 :) Thanks for the lightning fast fix :) Will this be released as a 3.3.2.1?

As there is a clear workaround by installing the perl module, I do not think this warrants a 3.3.2.1 release.

How does failing to build with your listed minimum dependencies not warrant a point release? This release does not build for a bunch of platforms, and telling those users to upgrade their version of perl or some perl module may be a non-starter for them.

Small detail: the next patch (point) release will be 3.3.3, regardless of when or how much goes into it.

LGTM, the patch fixes 3.3.2 builds for SLES 11 + 12, RHEL 6 + 7 .
Thanks a bunch for still supporting very basic (outdated) perl installations!

@t8m, @beldmit, re-approve, please?

@t8m why isn't a patch release being made? This would make many folks their work easier to resolve this

A patch release means a forced update for many users of OpenSSL so it creates additional work for many people. There is of course also some work required from the OpenSSL release managers to create the release but that is not so important for the decision.

So doing a new patch release should not be taken lightly and only fairly serious regressions should trigger such release.

I will be raising this issue in the next OTC meeting (next Tuesday).

Not building on supported platforms is a serious regression, and honestly, this regression should have been caught by automation prior to release.

Merged to the master and 3.3 branches. Thank you.

Is this 3.3.2.1 release or other? thanks

No new release is going to be done for this. The patch needs to be applied on top of the 3.3.2 tarball. Please see #25394

It is very disappointing. This means that a large number of CI scripts need to be revised for this, and it is very difficult. Because many Rust components involve OpenSSL and are automatically compiled by default. To improve compatibility, the commonly used base environment is manylinux2014. In this case, the patch tarball does not work. However, revising the basic environment may conflict with compatibility specifications and cannot be executed. :(

Sorry to jump in here, but I've been facing the same issue with a manylinux: auto config and a Rust+Python project (https://github.com/nyx-space/anise/actions/runs/10748687666/job/29812702558?pr=311). Is there a workaround we can use, or are we condemned to not build our libs until the next release of openssl? I admit that the crux of the issue is that the manylinux build just uses an old version of rhel here, but I don't know of a workaround to change that.

Thanks

P.S.: Openssl dev team, you're a core tenet of all software out there, so I'll take this opportunity to thank you for all of the hard work you've put into this lib over the decades.

Is there a workaround we can use, or are we condemned to not build our libs until the next release of openssl?

Yes there is. You can take the patch that came out of this PR (commit 40c8ebe).

BTW, we created a discussion category Release addendums a couple of days ago, and you'll find Release 3.3.2 errata there.

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

The only way is to force a rollback to 300.3.1+3.3.1 and wait for the new version to be released. That patch has no effect on this case.

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

The only way is to force a rollback to 300.3.1+3.3.1 and wait for the new version to be released. That patch has no effect on this case.

Yes, that's what my command does — I'm just noting that this took me a while to figure out as a non-Cargo-expert (and it seems like I'm not the only person on this thread running into this via a manylinux build of Rust software) and that perhaps others might appreciate the explicit command.

Works for me on amazon-linux2

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

Adding onto this, if you don't have a Cargo.lock, simply add glasser's command as a build step before the "build wheel" step: nyx-space/anise@02599b3 .