On 8/20/24 5:36 PM, Arne Vajhøj wrote:
On 8/20/2024 5:22 PM, Craig A. Berry wrote:
On 8/20/24 3:30 PM, jeffrey_dsi wrote:
On 2024-08-20, jeffrey_dsi <jeffrey@digitalsynergyinc.com> wrote:
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.
cd PIPELINE_DATA: fails the same as without the colon. I started an
issue with VSI so we'll see what they say.
Why do you think sftp has anything to do with SSL3? sftp runs over SSH,
not TLS.
SFTP is not using OpenSSH for TLS - FTP over TLS is FTPS.
But SFTP could use OpenSSL as basic cryptographic library
(AES, RSA etc.).
The OP said, "SSL doesn't appear to understand logicals," but it seems
unlikely OpenSSL, which may very well be used for some cryptographic
calls, is also used to do filename processing for sftp's cd command. We
don't even know if the upgrade to v8.4-2L3 included a switch from
traditional SSH to OpenSSH, which seems more likely to have caused a
switch in behavior. Which log files to examine and which configurations
to check will get you a lot farther if you look at the ones for the
product you're actually using.
We haven't yet heard whether Simon's suggestion of using a leading slash:
cd /pipeline_data
has been tried.
If there has been a switch to OpenSSH, it would be unsurprising if the
cd command encounters the following feature in a way that the old SSH
package didn't:
-----
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION
With DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION enabled, the conversion
routine decc$to_vms will only treat the first element of a UNIX style
name as a logical name if there is a leading slash (/).
-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)