https://bugs.kde.org/show_bug.cgi?id=482819
Fabian Vogt <fab...@ritter-vogt.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |NEEDSINFO
CC| |fab...@ritter-vogt.de
Resolution|--- |WAITINGFORINFO
--- Comment #20 from Fabian Vogt <fab...@ritter-vogt.de> ---
(In reply to Matt Fagnani from comment #8)
> I bisected this problem with qca from 2.3.7 to 2.3.8. The following first
> bad commit involved loading legacy openssl providers.
>
> 14eb1ae746c3c75afaef02b487ac65b3de85ad15 is the first bad commit
> commit 14eb1ae746c3c75afaef02b487ac65b3de85ad15
> Author: Fabian Vogt <fab...@ritter-vogt.de>
> Date: Fri Dec 22 13:36:00 2023 +0100
>
> plugins/qca-ossl: Actually try loading the legacy provider
>
> OSSL_PROVIDER_available returns true only for loaded providers, not
> whether
> a provider can be loaded. Use OSSL_PROVIDER_try_load instead, which also
> allows to keep the default fallback provider.
>
> plugins/qca-ossl/qca-ossl.cpp | 24 +++++-------------------
> 1 file changed, 5 insertions(+), 19 deletions(-)
My theory is that without this commit, using kwalletd6 with OpenSSL >= 3.0 will
just fail early enough that the broken code path is not even reached. Comment
19 is one major reason why that would be the case. You could confirm that by
creating an OpenSSL config which forces loading of default and legacy
providers:
$ cat openssl.cnf
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
And then trying kwallet6 with old qca + "OPENSSL_CONF=openssl.cnf kwallet6".
Locally I extracted the createSessionAlgorithmDhAes method into a standalone
executable (like comment 15, but more) and ran ltrace on that to get an
overview on the used code paths in qca and libcrypto. The call most likely to
fail is qca-ossl.cpp:DHKeyMaker::run() -> DH_generate_key, so I simulated that
by hardcoding a failure code at that point. The result is a segfault identical
to the one observed here.
Please do an ltrace of kwalletd6 by running "ltrace -fCl 'libcrypto*'
kwalletd6" and quote the output here. If some call fails, that should be
visible.
Question is why it fails on your system while it does not fail here. Maybe
there's an additional check for the parameter length in your OpenSSL version?
Upstream only checks for < 512:
https://github.com/openssl/openssl/blob/56e63f570bd5a479439bc6f6a2499f6b86ded341/crypto/dh/dh_key.c#L286
--
You are receiving this mail because:
You are watching all bug changes.
