cmkelley
Very Senior Member
I was having a thought about OpenSSL 1.1.1 and started the below as a response in a different thread, but I realize it's grown wildly off-topic for that thread. This is just a discussion point and a request for someone with more understanding than I to chime in as to if I'm on the right track or completely off the rails.
** IF ** I understand the situation correctly, and I very well may not, we'll never see OpenSSL 1.1.1 in a router that is being sold today. At some point in the future, with an as-yet-unreleased SoC, the SDK for that SoC might ship with a Kernel and userland that includes OpenSSL 1.1.1. But the chance of the SoC manufacturer updating existing SDKs for this seems wildly unlikely, and could wreck havoc on Entware, because there would be two fundamentally different kernels (and therefore APIs and other structures) for the same SoC - ensuring the user got the correct version would be challenging at best.
Bottom line, I believe we are stuck with the current situation where people who know what they're doing produce binaries that are statically linked against 1.1.1 (e.g. kvic's pixelserver-tls betas) or other libraries that can't be updated because they are tied into the SDK.
Big picture, this is starting to move beyond the intended use of a consumer-grade router. When stuff like OpenSSL 1.1.1 becomes very important to you, perhaps it's time to think of using perhaps a NUC or something similar running pfSense rather than a consumer-grade router. If you have to know-how to need and use stuff like OpenSSL 1.1.1, you've more than likely got the know-how to set up a pfSense solution. Statically linked binaries will, I'm fairly certain, take more memory, and even though swap files can be used, it's possible to run out of room for everything that has to be kept in memory if large numbers of programs start to be statically linked against never version libraries.
Don't get me wrong, it's crazy wonderful that RMerlin, kvic, thelonelycoder, Jack Yaz, Adamm, etc. are able to wring so much out of what is fundamentally a very simple system. And I'm very thankful for their efforts. And, I'm going to keep using my AC86U for either as long as it holds out, or until there becomes a very compelling reason to need something at the router level that the SDK doesn't support and can't be hacked on by someone with that knowledge.
** IF ** I understand the situation correctly, and I very well may not, we'll never see OpenSSL 1.1.1 in a router that is being sold today. At some point in the future, with an as-yet-unreleased SoC, the SDK for that SoC might ship with a Kernel and userland that includes OpenSSL 1.1.1. But the chance of the SoC manufacturer updating existing SDKs for this seems wildly unlikely, and could wreck havoc on Entware, because there would be two fundamentally different kernels (and therefore APIs and other structures) for the same SoC - ensuring the user got the correct version would be challenging at best.
Bottom line, I believe we are stuck with the current situation where people who know what they're doing produce binaries that are statically linked against 1.1.1 (e.g. kvic's pixelserver-tls betas) or other libraries that can't be updated because they are tied into the SDK.
Big picture, this is starting to move beyond the intended use of a consumer-grade router. When stuff like OpenSSL 1.1.1 becomes very important to you, perhaps it's time to think of using perhaps a NUC or something similar running pfSense rather than a consumer-grade router. If you have to know-how to need and use stuff like OpenSSL 1.1.1, you've more than likely got the know-how to set up a pfSense solution. Statically linked binaries will, I'm fairly certain, take more memory, and even though swap files can be used, it's possible to run out of room for everything that has to be kept in memory if large numbers of programs start to be statically linked against never version libraries.
Don't get me wrong, it's crazy wonderful that RMerlin, kvic, thelonelycoder, Jack Yaz, Adamm, etc. are able to wring so much out of what is fundamentally a very simple system. And I'm very thankful for their efforts. And, I'm going to keep using my AC86U for either as long as it holds out, or until there becomes a very compelling reason to need something at the router level that the SDK doesn't support and can't be hacked on by someone with that knowledge.
