Botan 3.0 pre-release checklist

[randombit]

Changes still needed prior to alpha1:

• X509_Certificate fails to parse a RSA-PSS certificate that was not signed by another RSA-PSS cert #3019
• Encode XMSS key derivation method in private key #3402
• Internal PK key refactoring for DL/EC (current WIP by Jack)
  • New approach for discrete logarithm keys #3210
  • EC equivalent work
• Final TLS 1.3 pieces
  • [TLS 1.3] Generalize ephemeral key handling callbacks #3322
  • [TLS 1.3] Cleanup Session Object #3316
  • [TLS 1.3] Use TLS::Callbacks::tls_session_established() #3337
  • Reduce proliferation of public headers related to TLS #3324
  • Clarify lifetime of TLS stack dependencies #3321
  • (Maybe optional): Introduce std::shared_ptr in Credentials_Manager::trusted_cas() and remove deprecated Creds_Mgr::cert_chain()
• Use simplified encodings for Kyber and Dilithium keys #3328
• PK RNG& lifetime issues
• Implement KEM FFI interfaces #3347
• TLS 1.3 migration Guide ([TLS 1.3] Update Migration Guide #3308)
• Get Dilithium X.509 working (Using Dilithium as PKI Signer Algo. #3208, Dilithium/Kyber in X.509 #3212)
• Improve (internal) handling of Signature Schemes that don't require an EMSA #3227
• Make Key_Constraints an "enum class"-like class #3225 / Key_Constraints should be an enum class #3211
• Look at Kyber key encoding (Kyber encoding may be outdated/incorrect #3179)
• ZFEC FFI (Expose ZFEC functionality via the C-compatible FFI interface #3190)
• Convert the remaining TLS enums to enum class #3146
• Stablize Supported Platforms for Botan 3.0 #3169
• Remove use of raw pointers where possible (Remove raw pointers from the public interface #3216 and Use smart pointers (std::unique_ptr) in API then ownership is transferred #2677)
• Maybe more std::span (Extend/Update (public) APIs with std::span overloads #3318)

After alpha1, before final release:

• Test builds of KeepassXC, SoftHSM, RNP, etc (Jack)
• Review documentation especially the migration guide (Jack)
• Complete the change notes (Jack)
• Run the one-off checks and static analyzers (clang-tidy, test_all_configs.py, etc)

Current timeline which will probably not be met :)

• Alpha1 on Feb 13th
• 3.0 release candidate on March 6th
• If all goes well, 3.0.0 March 13th

Revised schedules posted below.

[reneme]

I'd be glad to have experimental modules in 3.0 as well. Especially to use for the (upcoming) PQC implementations. #3110

[randombit]

There is still a lot of work in the queue and additionally Mailman is broken on my mail box, I'll need to upgrade/migrate to Mailman3 in order to send out any announcements. That's probably going to eat an entire day for me.

New schedule:

• Alpha1 Alpha2 on March 6th
• RC on March 20th
• 3.0.0 April 3rd

If things get done faster than I expect we can always release Alpha2 early and adjust as we go.

I forgot we actually already tagged an alpha1, way back in Feb 2022.

[randombit]

There has been a lot of work and some nice convergence in the last 3 weeks - more TLS improvements, the internal signature padding improvements, a lot of clang-tidy fixes, and testing clean with the latest Wycheproof. But ... we are not all the way there just yet.

Right now I'm leaning towards keeping the timeline as it except for skipping alpha2 altogether and going straight to the RC on March 20th and 3.0.0 in early April. If the RC doesn't seem ready in time that probably does delay 3.0.0 since we probably do want to give a couple of weeks for people to kick the tires, lest we have to immediately do a patch release fixing silly bugs. Given the recent rate of progress, and the relatively limited number of open todos I think RC on March 20th is still achievable.

[randombit]

Things are going exactly to plan, ie only slightly behind schedule.

I need to review #3409 #3411 and #3412 before the RC.

Everything else (eg EC key refactoring work) is delayed until post 3.0, and so is either cancelled or will be limited to what we can accomplish without breaking compatability.

I think best course right now is to delay everything one week from the prior schedule, ie RC is now March 27th and final release is April 10th.

Shifting the release schedule to the second Monday of the quarter is actually nicer as it avoids Jan 1, April 1, and July 4th as potential conflicts.

[randombit]

Also #3019 and #3402 should get fixed but we can do both post-RC Both fixed now

[randombit]

So close :) The final must-have for the RC is #3409 and that's basically done, modulo one question and a small merge conflict.

I want to minimize anything disruptive or risky between the RC and the final release. My plan is basically

• Documentation/examples
• CLI improvements
• New tests if they occur to me
• Introducing std::span where low risk
• Cleaning up ticket backlog

Also I (still) need to fix mailman. Or give up on it and create a Substack.

[randombit]

OK down to the final moments. It would be nice for #3450 to be included in the RC, but not a must.

I am planning on creating the RC today, in my evening. Say ~11PM UTC.

[reneme]

May I propose a last-second API adaption in the Session_Manager (#3451) before the freeze. 😄

[randombit]

RC1 is tagged and released

https://botan.randombit.net/releases/Botan-3.0.0-rc1.tar.xz
https://botan.randombit.net/releases/Botan-3.0.0-rc1.tar.xz.asc

[randombit]

I want to get #3480 merged before the final release, but otherwise we're good to go. Current plan is to spin the final release tomorrow, in the evening my time.

[randombit]

Something personal came up, I will either spin the release very late tonight or possibly tomorrow depending on how it goes.

[randombit]

Done https://botan.randombit.net/releases/Botan-3.0.0.tar.xz