Comment 10 for bug 1979639

Thank you for working on this!

The proposed SRU carries quite a bit of regression risk I think, since there are many packages both in and out of the archive that may parse this file under various different circumstances. A regression that leads to a TLS failure, possibly across multiple packages at once, would be severe.

I wonder if it's acceptable to just fix nodejs in the archive to be able to handle this situation, on the basis that software (whether in the archive or not) needs to be able to be compatible with libssl3 if it expects to both examine the *system* openssl configuration and be functional on Ubuntu 22.04? This alternate approach would carry far less risk, and would avoid the conffile prompt (in cases where users have changed it). Why wouldn't this be acceptable?

If not, how long must we keep compatibility against libssl1.1 in our shipped openssl.cnf? What's the deprecation plan?

> either separately packaged (e.g. as an upgrade leftover)

These packages would be broken and not expected to work. Presumably they depended on libssl1.1 anyway. What would be the consequence of openssl declaring a Breaks against libssl1.1?

If we do end up proceeding with the approach you've put in the upload queue, then I think your Test Plan additionally needs:

* to verify that the default provider is indeed still being used by libssl3 (ie. the wrong configuration doesn't get used by accident)

* a basic smoke test of libssl3 to ensure that we aren't about to break the normal use of libssl3 for the entire archive