Problems following systems-flush

You could also add to that entry that wget up to the current 1.12 in the package repo (let alone the BB version) may fail with many websites that now demand newer versions of TLS/SSL than it supports.

I have made builds of LibreSSL-2.6.4 and wget-1.19.5 that seem to work OK together on such sites but no time yet for the QA needed to package them for beta.
 
/df said:
You could also add to that entry that wget up to the current 1.12 in the package repo (let alone the BB version) may fail with many websites that now demand newer versions of TLS/SSL than it supports.

I have made builds of LibreSSL-2.6.4 and wget-1.19.5 that seem to work OK together on such sites but no time yet for the QA needed to package them for beta.
Click to expand...
Is the Curl version in the repository any more up to date than Wget?
 
It is (2010-10 vs 2009-09), but the same issue applies, because the problem is the OpenSSL-1.0.0 libraries /usr/lib/libssl.so and /usr/lib/libcrypto.so.

Similar issues apply to all the CF packages that may access the web and be forced by Google to use https: (eg ffmpeg, Python -- hence youtube-dl), as well as to the HumaxTV settop binary (which presumably is the cause of the error message Execution of request failed: https://gdata.youtube.com... in the TV Portal Youtube app).

The CF packages can be rebuilt against newer library versions. I chose the LIbreSSL implementation as easier to configure on the box than the original OpenSSL. wget builds easily on the box, but ffmpeg and Python seem to be too complex and would need to be cross-compiled.

For the HumaxTV binary, the library versions libssl.so.1.0.0 and libcrypto.so.1.0.0 are linked in and will be loaded from /usr/lib based on the environment settings with which the program is launched. Supposing that some combination of CF modifications, bind mounts and symlinks could persuade it to load with newer versions of the OpenSSL, it's quite possible that the ABI of the new versions -- the format of parameters passed between the program and the library -- may not be compatible with what was built into the program.
 
/df said:
it's quite possible that the ABI of the new versions -- the format of parameters passed between the program and the library -- may not be compatible with what was built into the program.
Click to expand...
Isn't that the whole point of the soname? It gets changed when the interface is no longer binary compatible. 1.0.2q appears to use the same soname as 1.0.0 so should be usable (in theory anyway, and if anyone could manage to build it).
 
I've had these lying around for a while so I've just pushed openssl 1.1.1a and wget 1.20 up to the beta repository.
prpr said:
Isn't that the whole point of the soname? It gets changed when the interface is no longer binary compatible. 1.0.2q appears to use the same soname as 1.0.0 so should be usable (in theory anyway, and if anyone could manage to build it).
Click to expand...
Exactly right, although you can't trust all software maintainers..

Using openssl 1.1 here, as well as it being much better than 1.0, means we keep the separation and do not risk upsetting the humaxtv binary.

I need to look at adding a trusted CA package but I've successfully used the new wget to download from github along with --no-check-certificate
The old wget binary is included as /mod/bin/wget-1.12 should anyone need it.

If you're doing a selective upgrade, you'll need to update header-files first:
Code: 
opkg update
opkg upgrade header-files
opkg upgrade wget
 
You must log in or register to reply here.
Back
Top