luci-ssl: make crypto lib generic

[aparcar]

Instead of a hard dependency, only require some crypto lib to be there. This simplifies upgrading while staying with the sames packages, i.e. using something like auc to upgrade the image without swichting the underlying crypto libary.

DRAF: package libustream-ssl doesn't exists yet.

[aparcar]

related openwrt/openwrt#12032

[hnyman]

Having a generic libustream dependency would be nice, sure, but it is not quite that simple.
How did you think to tackle the SSL certificate generation?
Currently a library-specific px5g variant is used, unless the luci-ssl-openssl is selected as it uses openssl-util. You seem to leave a generic px5g there, but also that is currently not generic and px5g is not even used by the openssl variant (which needs a modified command in uhttpd init script that utilises openssl-util).

The goal should still be to avoid installing two or more SSL libraries.

Changing the OpenWrt default SSL lib happens maybe once per 3-5 years, so the problem tried to be solved here does not happen that often.

It is a drawback / weakness / design fault of auc/attendedsysupgrade that it takes applies the (possibly changed) current defaults and also takes all installed packages, leading to possible conflict.

[aparcar]

It is a drawback / weakness / design fault of auc/attendedsysupgrade that it takes applies the (possibly changed) current defaults and also takes all installed packages, leading to possible conflict.

Do you have a better idea how to solve that? I'm happy to implement server/client logic but couldn't come up with a clean solution

[hnyman]

No clear answer, but I think that the problem is wider than just ustreamssl and related.
Similar problems arise between wpad/hostapd ssl variants and e.g. in firewall3-firewall4 transition (and their dependencies.
I mentioned the problematics with firewall in March 2022: https://forum.openwrt.org/t/rt3200-attended-sysupgrade-fails/123290/6
In that answer to you, I imagined a possible transition mapping table or blocklist or something. But that is likely too burdensome and not practical for all possible combinations like from 19.07 to 22.03 for all routers.

But my instinct is that with reasonable effort something could be done for the "usual suspects", to which I count at least wpad/hostapd ssl variants, ustreamssl variants and firewall.

Could the logic be something like:

• Classify the "defaults from the new build" separately from the package wishlist of "included in the old running firmware", and if there is a conflict, prefer the "default from new" variant
  • E.g. if the new image has built-in ustreamssl-mbedtls while the user's wishlist included ustreamssl-wolfssl, then believe the new built-in default and bake in ustreamssl-mbedtls.
• That logic should take user's explicit exclusions into account, so only "final" conflicts should be evaluated.
  (For example, if default is medbtls, but user explicitly removes it and includes openssl variant. Then there is no conflict and no action is needed.)
• Could auc have a pre-defined list of "current default ssl variant" in each supported branch and release tag? So that the process would know that "if going into 22.03.4, mbedtls will be the default".

firewall3-firewall4 transition (from 19.07 or 21.02 onwards? ) might also need to be handled somehow, or otherwise the future builds will keep including some old iptables related modules (as they were included in the old one). Some kind of firewall3 detection and notification to the user? (The user probably doesn't now the ip/ipt/kmods related, so the question is more problematic)

In general, this is the same weakness as our .config in general: there is no real way of knowing why a package has been included. If user first adds A that depends on B, then removes A from config, B will remain included. It is easy to accumulate unnecessary crust into the build if testing various packages, or the defaults/dependencies change. (I always start my own builds from a short recipe .config to avoid including old dependencies.)

[aparcar]

I wonder if for "default" users we should abstract the stuff away that is transparent to them anyway. Like we could depend on "firewall" and pick whatever OPKG suits best, not specifically firewall3 or firewall4. Same for wpad, we can just generically depend on it pull in whatever versions seems best. For libustream-ssl we have the default to mbedtls, so if I want to it generic, I ask to install luci-ssl which pulls in libustream-ssl which defaults to libustream-mbedtls. If I want OpenSSL for everything, I'd better say please install libustream-openssl specifically plus the generic luci-ssl.

[aparcar]

@jow- do you have an opinion here?

[Neustradamus]

@aparcar: What is the status of this PR?