[openssl-dev] OpenSSL on VMS v. HP -- SSLROOT v. SSL$ROOT (et al.)

[Steven M. Schweda]

   As a distraction from modern, important subjects, I offer the
following.

   For a long time, HP has distributed a modified version of OpenSSL for
VMS as "HP SSL" (most recently version V1.4-502, based (loosely?) on
0.9.8ze).

      http://h71000.www7.hp.com/openvms/security.html
      http://h71000.www7.hp.com/openvms/products/ssl/ssl.html    [Broken]
      http://h71000.www7.hp.com/openvms/products/ssl/ssl_doc.html
      http://h71000.www7.hp.com/openvms/products/ssl/ssl_source.html

   The set-up DCL script for the normal OpenSSL kit on VMS defines some
logical names, which point to particular directories.  For example:

  "OPENSSL" = "SSLINCLUDE:"
  "SSLCERTS" = "sslroot:[certs]"
  "SSLEXE" = "sslroot:[ALPHA_exe]"
  "SSLINCLUDE" = "sslroot:[include]"
  "SSLLIB" = "sslroot:[ALPHA_lib]"
  "SSLPRIVATE" = "sslroot:[private]"
  "SSLROOT" = "ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_0_1I.]"

   The HP-supplied kit uses similar logical names, but with a dollar
sign (which character is supposed to be reserved to HP).  For example:

  "OPENSSL" = "SSL$INCLUDE:"
  "SSL$CERT" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$CERTS" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$COM" = "SSL$ROOT:[COM]"
  "SSL$CONF" = "SSL$ROOT:[DEMOCA.CONF]"
  "SSL$CRL" = "SSL$ROOT:[DEMOCA.CRL]"
  "SSL$EXAMPLES" = "SYS$COMMON:[SYSHLP.EXAMPLES.SSL]"
  "SSL$EXE" = "SSL$ROOT:[Alpha_EXE]"
  "SSL$INCLUDE" = "SSL$ROOT:[INCLUDE]"
  "SSL$KEY" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$KEYS" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$PRIVATE" = "SSL$ROOT:[DEMOCA.PRIVATE]"
  "SSL$ROOT" = "SYS$SYSDEVICE:[VMS$COMMON.SSL.]"

   This would all be harmless, except that dollar-free names like
"SSLCERTS", "SSLPRIVATE", and "SSLROOT" are baked into the source code
(crypto/cryptlib.h and crypto/engine/eng_list.c), and the folks at HP
seem not to have noticed this.  One result of this oversight is that a
typical application, like, say, Wget, when built using the HP SSL kit,
can fail at run time when it can't find the OpenSSL configuration file
(because the HP SSL DCL set-up script defines "SSL$ROOT", not
"SSLROOT").  For example:

REX $ mcr [-.SRC.IA64L]wget --no-check-certificate https://google.com
--2015-06-22 14:16:13--  https://google.com/
Auto configuration failed
551552061:error:02001006:system library:fopen:no such device or address:BSS_FILE
:126:fopen('SSLROOT:[000000]openssl.cnf','r')
551552061:error:2006D002:BIO routines:BIO_new_file:system lib:BSS_FILE:131:
551552061:error:0E078002:configuration file routines:DEF_LOAD:system lib:CONF_DE
F:199:

   There's a simple work-around (not documented anywhere):
      DEFINE SSLROOT SSL$ROOT
(and perhaps similar commands for the other names, if needed), but it
might make some sense if the two relevant source files could be told to
use the alternate names.  For example, in crypto/cryptlib.h, instead of:

      #define X509_CERT_AREA          "SSLROOT:[000000]"
      #define X509_CERT_DIR           "SSLCERTS:"
      #define X509_CERT_FILE          "SSLCERTS:cert.pem"
      #define X509_PRIVATE_DIR        "SSLPRIVATE:"

perhaps:

      #ifdef VMS_VENDOR
      # define X509_CERT_AREA         "SSL$ROOT:[000000]"
      # define X509_CERT_DIR          "SSL$CERTS:"
      # define X509_CERT_FILE         "SSL$CERTS:cert.pem"
      # define X509_PRIVATE_DIR       "SSL$PRIVATE:"
      #else
      # define X509_CERT_AREA         "SSLROOT:[000000]"
      # define X509_CERT_DIR          "SSLCERTS:"
      # define X509_CERT_FILE         "SSLCERTS:cert.pem"
      # define X509_PRIVATE_DIR       "SSLPRIVATE:"
      #endif

with something similar in crypto/engine/eng_list.c, like, say:

      #ifdef OPENSSL_SYS_VMS
      # ifdef VMS_VENDOR
      #  define VMS_ENGINES "SSL$ROOT:[ENGINES]"
      # else
      #  define VMS_ENGINES "SSLROOT:[ENGINES]"
      # endif
          if((load_dir = getenv("OPENSSL_ENGINES")) == 0)
           load_dir = VMS_ENGINES;
      #else

   On their own, these changes would not fix anything, but they would
make it relatively easy for HP (or their inheritors) to build the stuff
with the alternate (vendor-preferred) logical names baked in instead of
the normal ones.  At which point it would still be all their fault, but
at least we tried.

   Ideally, I claim, the file/path names with these logical-name
components would be defined at some higher level in the source tree,
where they'd be obvious and easy to change (instead of in the
subterranean files where they're found now), but I don't know where a
good spot would be.  If someone who knows more than I (almost anyone)
has a better organizational plan, then it'd most likely be ok with me,
but I'd settle for a little fiddling in the caves, as suggested above.

   As always, thanks for your consideration.

------------------------------------------------------------------------

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547