VSI SSL3 3.0-12 and SSL111 V1.1.1W Release notes post-install task needs revision

[agn453]

I've just installed the appropriate VSI SSL3 3.0-12 and VSI SSL111 V1.1.1W kits on both my x86 and axp community licensed systems.

I notice that the release notes post-installation tasks suggest adding startup code to SYSTARTUP-VMS.COM for both using

Code: Select all

$ if f$search("sys$startup:ssl111$startup.com") .nes. ""
$ then
$ @sys$startup:ssl111$startup.com
$ endif
$ if f$search("sys$startup:ssl3$startup.com") .nes. ""
$ then
$    @sys$startup:ssl3$startup.com
$ endif

However, when I do this and reboot the startup dialog reports the following when it runs SYSTARTUP_VMS.COM -

Code: Select all

%DCL-I-SUPERSEDE, previous value of SSL111$ROOT has been superseded
%DCL-I-SUPERSEDE, previous value of SSL3$ROOT has been superseded

Upon investigation I see that the SSL startup command files have already invoked by the SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM command procedure.

Therefore this part of the post-installation notes would seem to be redundant - there's no need to redo this again in the site-specific startup. This should be noted in the release notes.

As an aside - I also noticed that the x86 version of SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM for OpenVMS V9.2-1 invokes all of the sys$startup:ssl*$startup.com routines, whereas the AXP OpenVMS V8.4-2L1 version only does the legacy sys$startup:ssl$startup.com and sys$startup:ssl1$startup.com ones - so that I do need to include the SSL3 startup in the AXP's site-specific startup.

Tony

[dgordon]

OpenSSL on VMS brings out some interesting problems and you're seeing the "belt and suspenders" approach that we have adopted.

For any given version of the OS, there are components linked against a specific version of OpenSSL. In practice, the OS uses the "current" version available during the development cycle. It's an unfortunate truth that the OpenSSL APIs have not always been upwardly compatible from version to version. That's why OpenSSL is kitted such that multiple versions can coexist on a single version of the OS. A freshly installed version of OpenVMS installs the version required for that version. Upgraded versions of VMS may install a newer version of OpenSSL if required, but will not remove older versions as part of the upgrade. Note that I'm talking about OpenSSL versions (1.0, 1.1, 1.1.1, 3.0...) rather than the particular release ("w" or "-12") here. The OpenVMS startup sequence needs to insure that the startup file for the "system" version of OpenSSL runs.

We also know that customers might have older applications that have not been updated to a recent version of OpenSSL. For that reason, a customer might install an older, or even deprecated version of OpenSSL, or might be developing against a newer version of OpenSSL than the version required by the OS. The individual kits and release notes tell you how to run the startup file for the version being installed. Running the startup file twice is better than not running it at all.

There's a valid argument that the startup files should use /NOLOG when creating the logical names for a cleaner startup experience. On the other hand, I'm sure someone would prefer to know that the file is running multiple times.