https://bugs.kde.org/show_bug.cgi?id=482819

Nekto Oleg <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|                            |https://invent.kde.org/libr
                   |                            |aries/qca/-/commit/a818965a
                   |                            |3e67f1212ee5fed1d70a9a8b4ce
                   |                            |d8dcc
             Status|CONFIRMED                   |RESOLVED
            Version|                            |2.3.11
  Fixed/Implemented|                            |
                 In|                            |
         Resolution|---                         |FIXED

--- Comment #32 from Nekto Oleg <[email protected]> ---
Git commit a818965a3e67f1212ee5fed1d70a9a8b4ced8dcc by Nekto Oleg.
Committed on 02/08/2026 at 05:15.
Pushed by aacid into branch 'master'.

qca-ossl: load the default OpenSSL provider explicitly

Activating any provider disables OpenSSL 3's implicit loading of the
default one. Qt unloads the default provider while setting up its TLS
backend, so loading only the legacy provider afterwards leaves the
library context without the algorithms DH key generation needs.
DH_generate_key() then fails silently and PrivateKey::deriveKey()
dereferences the resulting null key.

Applications reach this through the Secret Service API: ksecretd
segfaults in deriveKey() whenever a client opens a session using the
dh-ietf1024-sha256-aes128-cbc-pkcs7 algorithm, which is what every
libsecret-based client requests.

Loading the default provider is a no-op when it is already present, so
setups that were never affected keep their current behaviour.
FIXED-IN: 2.3.11

M  +5    -0    plugins/qca-ossl/qca-ossl.cpp

https://invent.kde.org/libraries/qca/-/commit/a818965a3e67f1212ee5fed1d70a9a8b4ced8dcc

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to