As python just uses the system installed OpenSSL we want to be forcing an upgrade to the most current OpenSSL on an ongoing basis. This will certainly not be the last time OpenSSL has a vulnerability...

I had initially proposed a CLI flag to skip the system stuff. I don't want to be entering my password into scripts all the time. I also don't want to wait around for apt all the time. A CLI flag would leave the option for default users to still get the baby sitting we have here. Someone recently got banned from apt connections or something and so they couldn't use the installer for a few hours. That's kind of the top level perspective that brought up this topic. I wonder if the full suite of mature installers at this time has any bearing on the trade offs here.

@hoffmang9 @altendky
Thank you for the comment.
I'll change the PR to:

• Add a cli flag to set PACKAGE_INSTALL_REQUIRED forcibly to 0
• Set PACKAGE_INSTALL_REQUIRED=1 when OpenSSL version is old if the flag above is not specified.

I think to check if openssl is old I would basically expect to do an apt update and then ask it. At that point we maybe may as well just do the install instead? Unless you can ask apt if there are new versions without doing the global/sudo-requiring apt update?

OpenSSL will be updated only when version < 3.0.2 or 1.1.1n or 1.0.2zd is installed.
We won't update openssl just because there are new versions.

I thought Gene wanted us to do that. Otherwise we have to push an updated install.sh to everyone to get the benefit of this when there's another important update to openssl. I'm on the fence about it being our place to update the user's system, but the upside is certainly pretty straightforward.

Overhauled entire construct of install.sh.
Added -s option. (Skip python install)
If you don't specify -s, then install.sh works just the same as usual.
If you specify -s, Python installation (as well as openssl/sqlite) will be skipped.