|
|
Post by metro on Apr 2, 2022 21:32:13 GMT -5
I have tried Lin64, lin32, win64, win32 (WINE on LINUX) I get URL not found. I then used same code using 4.51 to test it was not my machine and it works
|
|
|
|
Post by Carl Gundel on Apr 13, 2022 21:50:15 GMT -5
I have tried Lin64, lin32, win64, win32 (WINE on LINUX) I get URL not found. I then used same code using 4.51 to test it was not my machine and it works
Okay, I see the same sort of thing but only on Linux. I have no trouble with the testHttpget.bas example that comes with LB5-353 when I test on Mac OS or Windows. Both URLs return results. On my Ubuntu 32-system if I set the VW_LIBCRYPTO env variable before a launch LB5 I get a good result. Here is the command I used. The location and name of your library file may be different. export VW_LIBCRYPTO=/lib/i386-linux-gnu/libcrypto.so.1.0.0 I'm eager to hear if this is helpful for you. I'm curious about your issues on Windows, which works for me. I will do what I can to make this sort of thing unnecessary as much as possible in future versions. |
|
|
|
Post by metro on Apr 14, 2022 8:30:14 GMT -5
I have tried Lin64, lin32, win64, win32 (WINE on LINUX) I get URL not found. I then used same code using 4.51 to test it was not my machine and it works
Okay, I see the same sort of thing but only on Linux. I have no trouble with the testHttpget.bas example that comes with LB5-353 when I test on Mac OS or Windows. Both URLs return results. On my Ubuntu 32-system if I set the VW_LIBCRYPTO env variable before a launch LB5 I get a good result. Here is the command I used. The location and name of your library file may be different. export VW_LIBCRYPTO=/lib/i386-linux-gnu/libcrypto.so.1.0.0 I'm eager to hear if this is helpful for you. I'm curious about your issues on Windows, which works for me. I will do what I can to make this sort of thing unnecessary as much as possible in future versions. Thanks Carl, I thought my windows issues may have been related to WINE & LINUX. so I copied 32 & 64 bit setups to my WIN10 laptop httpget$ fails to retrieve url's that start with https; .
This works on windows for me print httpget$("http://www.libertybasic.com") but not the Google url
I'm working on solving the linux issue and have found the library I believe I need for 64 bit /usr/lib/x86_64-linux-gnu/libcrypto.so setting the env variable in my start-up script has not worked, just reading up on it now to make sure I have it set-up correctly
metro
|
|
|
|
Post by Carl Gundel on Apr 14, 2022 8:37:53 GMT -5
Thanks Carl, I thought my windows issues may have been related to WINE & LINUX. so I copied 32 & 64 bit setups to my WIN10 laptop httpget$ fails to retrieve url's that start with https; .
This works on windows for me print httpget$("http://www.libertybasic.com") but not the Google url
I'm working on solving the linux issue and have found the library I believe I need for 64 bit /usr/lib/x86_64-linux-gnu/libcrypto.so setting the env variable in my start-up script has not worked, just reading up on it now to make sure I have it set-up correctly Is that a link to the library, or it is the path to the actual library? I ask because the filename doesn't have any version info in it, and links are sometimes like that. I don't know if it will make any difference either way, but just thought it made sense to ask. |
|
|
|
Post by metro on Apr 14, 2022 9:57:09 GMT -5
Thanks Carl, I thought my windows issues may have been related to WINE & LINUX. so I copied 32 & 64 bit setups to my WIN10 laptop httpget$ fails to retrieve url's that start with https; .
This works on windows for me print httpget$("http://www.libertybasic.com") but not the Google url
I'm working on solving the linux issue and have found the library I believe I need for 64 bit /usr/lib/x86_64-linux-gnu/libcrypto.so setting the env variable in my start-up script has not worked, just reading up on it now to make sure I have it set-up correctly Is that a link to the library, or it is the path to the actual library? I ask because the filename doesn't have any version info in it, and links are sometimes like that. I don't know if it will make any difference either way, but just thought it made sense to ask. Thanks Carl, I seem to be out of my depth here. You are correct, now believe that was a link. I seem to have both /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 and /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 I have used both paths (at different times) in my start-up script and still no luck....
been awake 20 hours will have another go in the morning..
|
|
|
|
Post by Carl Gundel on Apr 14, 2022 11:19:32 GMT -5
Thanks Carl, I seem to be out of my depth here. You are correct, now believe that was a link. I seem to have both /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 and /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 I have used both paths (at different times) in my start-up script and still no luck....
been awake 20 hours will have another go in the morning..
I will give it a try on a 64-bit Linux system and see what happens. |
|
|
|
Post by metro on Apr 14, 2022 22:28:37 GMT -5
well, I believe the env variable is set. after using printenv VW_LIBCRYTPTO I get the variable listed...
however, no luck getting httpget$(url's) to return a result.
I am unable to test 32bit LB5-353 as I get errors on my Linux Mint 19.x 64bit straight up, on start of LB5
metro@OptiPlex:~$ export VW_LIBCRYPTO=/lib/i386-linux-gnu/libcrypto.so.1.0.0
metro@OptiPlex:~$ printenv VW_LIBCRYPTO
/lib/i386-linux-gnu/libcrypto.so.1.0.0
|
|
|
|
Post by Chris Iverson on Apr 14, 2022 23:48:37 GMT -5
Here are my results, on Ubuntu 20.04 running under WSL2. First, the list of libcrypto versions on the system: chris@MAKOTO:/opt/lb5-alpha-32$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.1 (libc6) => /usr/lib/i386-linux-gnu/libcrypto.so.1.1
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.soSo, 64-bit and 32-bit versions of libcrypto.so.1.1, and a link(libcrypto.so) to the 64-bit version. The 32-bit version doesn't have a link, and I think this is a Ubuntu packaging error, because the 64-bit version didn't have a link a while back, either, even though there WAS one on the Raspberry Pi. I'm also running these tests with an injected library I created myself that outputs the list of libraries that the program attempts to load(and if those attempts succeed.) So, starting with the 64-bit version, with the environment variable blank: chris@MAKOTO:/opt/lb5-alpha$ export VW_LIBCRYPTO=
chris@MAKOTO:/opt/lb5-alpha$ LD_PRELOAD=./hook64.so ./lin64-353 lb5alpha64.im
dlopen() - (null) - 0x00000101 - 0x00007fea47413190
dlopen() - libXft.so.2 - 0x00000101 - 0x000000000407d750
dlopen() - libXcursor.so.1 - 0x00000001 - 0x0000000000cd0f10
dlopen() - - 0x00000101 - 0x00007fea47413190
dlopen() - libcrypto.so - 0x00000101 - 0x00000000040dda20Result: libcrypto.so link opened successfully(last column is the handle to the library, which would be null if not found/not loaded), but gives the error "URL not found: www.google.com" or "URL not found: www.libertybasic.com" when attempting to run the testHttpget.bas file(and commenting out the google line for the second test). Second attempt: 64-bit, with environment variable filled in: chris@MAKOTO:/opt/lb5-alpha$ export VW_LIBCRYPTO=/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
chris@MAKOTO:/opt/lb5-alpha$ LD_PRELOAD=./hook64.so ./lin64-353 lb5alpha64.im
dlopen() - (null) - 0x00000101 - 0x00007fd6b862c190
dlopen() - libXft.so.2 - 0x00000101 - 0x000000000481a750
dlopen() - libXcursor.so.1 - 0x00000001 - 0x000000000146d460
dlopen() - /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 - 0x00000101 - 0x000000000482e660
dlopen() - libcrypto.so - 0x00000101 - 0x000000000482e660You can see that it did explicitly open the library this time, but I still got failure, for both methods. Next test: 32-bit, no environment variable. chris@MAKOTO:/opt/lb5-alpha-32$ export VW_LIBCRYPTO=
chris@MAKOTO:/opt/lb5-alpha-32$ LD_PRELOAD=./hook32.so ./lin32-353 lb5alpha.im
dlopen() - (null) - 0x00000101 - 0xf7fd9990
dlopen() - libXft.so.2 - 0x00000101 - 0x0b652870
dlopen() - libXcursor.so.1 - 0x00000001 - 0x0b6621e0
dlopen() - - 0x00000101 - 0xf7fd9990
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000Well, that's interesting. When I first opened LB5, only the first libcrypto.so load attempt showed up. Then, when I ran the test file, it stopped at the google line, with the same error, but all of those other attempts to load libcrypto showed up. Even more interesting, I get a similar result(with a much smaller number of attempts to load libcrypto) if I comment out the google line: chris@MAKOTO:/opt/lb5-alpha-32$ LD_PRELOAD=./hook32.so ./lin32-353 lb5alpha.im
dlopen() - (null) - 0x00000101 - 0xf7fb6990
dlopen() - libXft.so.2 - 0x00000101 - 0x0ad09870
dlopen() - libXcursor.so.1 - 0x00000001 - 0x08d1f320
dlopen() - - 0x00000101 - 0xf7fb6990
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000Ok, so let's try 32-bit, with the environment variable. chris@MAKOTO:/opt/lb5-alpha-32$ export VW_LIBCRYPTO=/usr/lib/i386-linux-gnu/libcrypto.so.1.1
chris@MAKOTO:/opt/lb5-alpha-32$ LD_PRELOAD=./hook32.so ./lin32-353 lb5alpha.im
dlopen() - (null) - 0x00000101 - 0xf7f48990
dlopen() - libXft.so.2 - 0x00000101 - 0x0b390870
dlopen() - libXcursor.so.1 - 0x00000001 - 0x093a6320
dlopen() - /usr/lib/i386-linux-gnu/libcrypto.so.1.1 - 0x00000101 - 0x0b3a1780
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000
dlopen() - libcrypto.so - 0x00000101 - 0000000000So, it successfully opened the full path to libcrypto thanks to the environment variable, but then it keeps trying and failing to load "libcrypto.so", and gives a similar result to the no environment variable attempt. Similar results to just the libertybasic.com line, as well. Out of curiosity, I decided to make the link to the 32-bit version of the library, and see what happens. chris@MAKOTO:/opt/lb5-alpha-32$ cd /usr/lib/i386-linux-gnu/
chris@MAKOTO:/usr/lib/i386-linux-gnu$ sudo ln -s libcrypto.so.1.1 libcrypto.so
[sudo] password for chris:
chris@MAKOTO:/usr/lib/i386-linux-gnu$ sudo ldconfig
/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link
chris@MAKOTO:/usr/lib/i386-linux-gnu$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.1 (libc6) => /usr/lib/i386-linux-gnu/libcrypto.so.1.1
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
libcrypto.so (libc6) => /usr/lib/i386-linux-gnu/libcrypto.soI make the link in the right folder, I run ldconfig to refresh the library loader cache, and then check to see if the link shows up in the cache(which it now does). Let's try that first test again. 32-bit, no environment variable. Result: chris@MAKOTO:/opt/lb5-alpha-32$ export VW_LIBCRYPTO=
chris@MAKOTO:/opt/lb5-alpha-32$ LD_PRELOAD=./hook32.so ./lin32-353 lb5alpha.im
dlopen() - (null) - 0x00000101 - 0xf7f92990
dlopen() - libXft.so.2 - 0x00000101 - 0x0ba61870
dlopen() - libXcursor.so.1 - 0x00000001 - 0x0ba6f3b0
dlopen() - - 0x00000101 - 0xf7f92990
dlopen() - libcrypto.so - 0x00000101 - 0x0ba70d70Basically identical to the 64-bit version. Library loads, but neither URL will download. Out of curiosity, 32-bit with environment variable set: chris@MAKOTO:/opt/lb5-alpha-32$ export VW_LIBCRYPTO=/usr/lib/i386-linux-gnu/libcrypto.so.1.1
chris@MAKOTO:/opt/lb5-alpha-32$ LD_PRELOAD=./hook32.so ./lin32-353 lb5alpha.im
dlopen() - (null) - 0x00000101 - 0xf7fe2990
dlopen() - libXft.so.2 - 0x00000101 - 0x0a596870
dlopen() - libXcursor.so.1 - 0x00000001 - 0x0a5a01a0
dlopen() - /usr/lib/i386-linux-gnu/libcrypto.so.1.1 - 0x00000101 - 0x085abdc0
dlopen() - libcrypto.so - 0x00000101 - 0x085abdc0Also identical to the 64-bit version. Explicit path loads library, second libcrypto open attempt returns the same handle, URLs still "not found". So, more digging necessary. |
|
|
|
Post by Chris Iverson on Apr 15, 2022 19:33:40 GMT -5
I think I might know what the issue is, I'm just working to confirm it.
Doing some debugging of the library loading process, I got an error message that the symbol "SSLeay" couldn't be found.
This is a symbol/function from OpenSSL, but it was deprecated, and removed in OpenSSL 1.1, which is what Ubuntu 20.04 uses.
I think it currently requires OpenSSL 1.0 to function, and I think Carl's response hints at that. (The library name he used was libcrypto.so.1.0.0)
I think Ubuntu 18.04 had both OpenSSL versions at some point, I'm trying to reinstall Ubuntu 18.04 on something right now to do a quick test. (As far as I can tell, there's no OpenSSL 1.0.2 package available for Ubuntu 20.04, as that version was no longer supported by that point, IIRC)
EDIT: And I can confirm that that worked, 64-bit. Using the environment variable to point to OpenSSL 1.0, or making a symlink from libcrypto.so -> libcrypto.so.1.0.0, both caused BOTH httpget$() calls to work, with no errors.
|
|
|
|
Post by metro on Apr 15, 2022 20:35:01 GMT -5
Wow, great find Chris. I am a little confused, Synaptic shows I have OpenSSl 1.0 installed. however in a terminal I get laurie@OptiPlex:~$ openssl version
OpenSSL 1.1.1 11 Sep 2018
laurie@OptiPlex:~$ ls -l libcrypto.so
lrwxrwxrwx 1 laurie laurie 18 Apr 16 09:18 libcrypto.so -> libcrypto.so.1.0.0
laurie@OptiPlex:~$
Still not working for me even with symlink. hmm more head-scratching today I think
|
|
|
|
Post by Chris Iverson on Apr 15, 2022 21:58:02 GMT -5
I think I see both of your issues, with the envvar method AND the symlink method.
#1, you say that you're using Linux Mint 64-bit, and that you can't get 32-bit LB5 to run.
I assume that means that you're using 64-bit LB5, but the environment variable you're setting is telling it to use the 32-bit libcrypto library(i386-linux-gnu folder instead of x86_64-linux-gnu). That won't work.
#2, You seem to have made that symlink in your home folder. For it to work, it has to be in the library folder(same as where libcrypto itself is), not your home folder.
To find the path to the libcrypto library, use the ldconfig -p command, combined with a grep for libcrypto, as I did in a post above. Use that path for the envvar, and go into that folder to make the symlink.
Edit: run the command like this:
chris@MAKOTO:/opt/lb5-alpha-32$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.1 (libc6) => /usr/lib/i386-linux-gnu/libcrypto.so.1.1
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
|
|
|
|
Post by metro on Apr 15, 2022 22:58:16 GMT -5
Thanks, Chris, I hate being a pain. I will sit and re-read what you have presented after some head-clearing in my shed.
I still do not understand what I'm doing wrong.
I have ...
laurie@OptiPlex:~$ printenv VW_LIBCRYPTO
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
laurie@OptiPlex:~$
laurie@OptiPlex:~$ cd /usr/lib/x86_64-linux-gnu/
laurie@OptiPlex:/usr/lib/x86_64-linux-gnu$ ln -s libcrypto.so.1.0.0 libcrypto.so
ln: failed to create symbolic link 'libcrypto.so': File exists
laurie@OptiPlex:/usr/lib/x86_64-linux-gnu$
I'll give it a couple of hours and get back to it, it will be something simple.
|
|
|
|
Post by Chris Iverson on Apr 15, 2022 23:01:45 GMT -5
Ok, for the first one, that seems to be correct. That's not working?
For the second one, it's failing to create the link, because the link already exists, possibly pointing to the other version.
You would have to delete the link first to recreate it.
EDIT: Just tried it again, on Ubuntu 18.04, using the envvar method, 64-bit.
Check to see where the library is
chris@MAKOTO:/opt/lb5-alpha$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
Set the environment variable to the path shown
chris@MAKOTO:/opt/lb5-alpha$ export VW_LIBCRYPTO=/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
chris@MAKOTO:/opt/lb5-alpha$ printenv VW_LIBCRYPTO
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
Run LB5
chris@MAKOTO:/opt/lb5-alpha$ ./lin64-353 lb5alpha64.im
And it worked.
I wonder if Linux Mint is doing something different. I'll take a look.
|
|
|
|
Post by metro on Apr 16, 2022 0:13:27 GMT -5
Thanks again Chris.
laurie@OptiPlex:~$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (libc6) => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
laurie@OptiPlex:~$ ldconfig -p | grep libcrypto
libcrypto.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (libc6) => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
#!/bin/bash
./lin64-353 lb5alpha64.im
I am intrigued that sudo ln -s libcrypto.so libcrypto.so.1.0.0 is then displayed the other way around
when I ls -la
-rw-r--r-- 1 root root 61488 Jan 24 20:53 libcrypt.a
-rw-r--r-- 1 root root 5413392 Mar 9 20:13 libcrypto.a
lrwxrwxrwx 1 root root 12 Apr 16 12:48 libcrypto.so.1.0.0 -> libcrypto.so
-rw-r--r-- 1 root root 2917216 Mar 9 20:13 libcrypto.so.1.1
|
|
|
|
Post by Chris Iverson on Apr 16, 2022 0:33:23 GMT -5
That's certainly strange. I did an install of Linux Mint 19.3 just to test things myself, and I don't see anything like that.
Do you have a libcrypto.so listed there? Or does the libcrypto.so.1.0.0 show as a broken link? The reason I ask is that that "link" seems to have been created today, judging by the date.
In my own Linux Mint install, I don't have any links. Just libcrypto.so.1.1 and libcrypto.so.1.0.0.
I hate to ask, but might you have accidentally overwritten the actual libcrypto.so.1.0.0 file with the link?
If you think you have, then try reinstalling OpenSSL 1.0 from APT.
Run this command in the terminal:
sudo apt reinstall libssl1.0.0
And see if that changes what shows up for ls -la in that folder.
|
|
