Skip to content

Conversation

geofft
Copy link
Collaborator

@geofft geofft commented Sep 17, 2025

No description provided.

@geofft geofft force-pushed the geofft/openssl-3.5.3 branch from b2f8f88 to 892a5a9 Compare September 18, 2025 12:28
@geofft
Copy link
Collaborator Author

geofft commented Sep 18, 2025

cc @Edward-Knight

Copy link
Contributor

@Edward-Knight Edward-Knight left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
I see the vlenb patch hit in 3.5.3 as well as a fix for the OPENSSL_VERSION_NUMBER that now (correctly) makes it end in 0xf (for final I presume?)

edit: also checked and the hash is correct too

@geofft geofft merged commit 9793ac5 into main Sep 18, 2025
48 checks passed
@geofft geofft deleted the geofft/openssl-3.5.3 branch September 18, 2025 15:52
@geofft
Copy link
Collaborator Author

geofft commented Oct 1, 2025

as well as a fix for the OPENSSL_VERSION_NUMBER that now (correctly) makes it end in 0xf (for final I presume?)

Turns out this was a mistake that was only present in 3.5.3. The 1.x series was documented as: "The status nibble has one of the values 0 for development, 1 to e for betas 1 to 14, and f for release." But the 3.x series was always documented as: "OPENSSL_VERSION_NUMBER is a combination of the major, minor and patch version into a single integer 0xMNN00PP0L". 3.5.3 was the only version that used 0xF; they reverted that for 3.5.4 and this didn't get into any other releases. (See openssl/project#1621 and linked issues.)

@Edward-Knight
Copy link
Contributor

How 0xfun

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants