Sujet : Re: SSL3 on OpenVMS V8.4-2L3
De : seaohveh (at) *nospam* hoffmanlabs.invalid (Stephen Hoffman)
Groupes : comp.os.vmsDate : 25. Aug 2024, 02:55:50
Autres entêtes
Organisation : HoffmanLabs LLC
Message-ID : <vae2v6$1k0a7$1@dont-email.me>
References : 1
User-Agent : Unison/2.2
On 2024-08-20 17:43:31 +0000, jeffrey_dsi said:
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13 after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to the VMS system. In the script it did a "cd pipeline_data" which was a system logical for where the file needs to go. This doesn't work as SSL doesn't appear to understand logicals. I had to change it to "cd /lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device name except for sys$manager:logicals.com. I put a remark in the logicals.com to remind me of the new dependency if that logical changes.
Given sftp is built atop ssh, and TLS itself knows ~zilch about cd and file paths, I'm not sure why any TLS version is involved here.
The OpenSSH version would seem more central to this morass, and maybe the OpenSSH port isn't playing nice with logical names, as compared with the older HPE TCP/IP Services ssh stack.
(I haven't updated the local box to the OpenSSH V8.9-1I port — though OpenSSH 9.8 is current — so no way to check what that links against. It's possible OpenSSH might.)
(I? In a version string? Seriously?)
See if the installed ssh stack makes a difference, if VSI didn't already suggest that. Or push over the file and pre-process it on OpenVMS. Or select a login for the ssh that gets you to the right path. Otherwise, you're waiting for VSI to fix the bug.
-- Pure Personal Opinion | HoffmanLabs LLC