[qca] [Bug 482819] kwalletd6 sometimes crashed in QCA::PrivateKey::deriveKey when starting Proton VPN GUI

[Fabian Vogt]

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

Fabian Vogt <fabian at ritter-vogt.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WAITINGFORINFO
             Status|REPORTED                    |NEEDSINFO

--- Comment #23 from Fabian Vogt <fabian at ritter-vogt.de> ---
(In reply to Matt Fagnani from comment #21)
> I created an OpenPGP key in KGpg. I exported my Blowfish encrypted wallet,
> and then I deleted it in kwalletmanager. I created a new wallet with my
> OpenPGP key in kwalletmanager. The Proton VPN GUI and kwalletd6 didn't crash
> when I started the Proton VPN GUI, but when I tried to log in to Proton VPN,
> kwalletd6 crashed with the same trace and an error popup like "Something
> went wrong. We're sorry, a problem occurred" was shown in Proton VPN GUI. I
> think the problem occurred when logging in instead of starting because the
> wallet was empty at that point. This test and the following were with qca
> 2.3.8 plus the patch in comment 11.
> 
> In another Plasma session, I closed the new wallet encrypted with the
> OpenPGP key in kwalletmanager. I ran killall kwalletd6 twice as suggested in
> comment 9. I ran OPENSSL_CONF=openssl.cnf kwalletd6 I opened the wallet in
> kwalletmanager. I ran Proton VPN GUI and logged in. The login completed
> without the kwalletd6 crash or the Proton VPN error happening. So this test
> supports your theory.

Not sure. That openssl.cnf should be a noop and be equivalent to qca 2.3.8
with upstream default openssl config. Can you try with an empty file for
OPENSSL_CONF?

> I closed the wallet again in kwalletmanager. I ran killall kwalletd6 twice.
> I ran ltrace -fCl 'libcrypto*' kwalletd6. Proton VPN crashed when starting,
> and kwalletd6 also crashed as shown in the following output.
> 
> kf.wallet.kwalletd: Lacking a socket, pipe: 0 env: 0
> ...

For some weird reason it only logs QtCore -> OpenSSL calls, but not those
coming from QCA...
Please try "ltrace -fCe 'DH_*+OSSL_*' kwalletd6"

> Before those tests, I attached gdb to kwalletd6 with gdb -p $(pidof
> kwalletd6). I set a breakpoint with b kwalletfreedesktopservice.cpp:415. I
> stepped through each line. In the line auto privateKey =
> QCA::PrivateKey(keygen.createDH(dlGroup)); I saw that the provider and
> algorithm had null pointers.

FWICT that might be fine.

> Fedora's default crypto policy has a minimum DH key size of 2048 as I
> mentioned in comment 17. The DH keys generated in
> KWalletFreedesktopService::createSessionAlgorithmDhAes used QCA::IETF_1024.

AFAICT the crypto policies only affect SSL/TLS, not use of DH_* directly.

> Could that be an additional check leading to the legacy providers' path
> being used? Thanks.

I don't think providers have anything to do with DH_* methods which are part of
OpenSSL core.

(In reply to Matt Fagnani from comment #22)
> I think I've found why the problem happened on my system but not yours. The
> openssl config file /etc/pki/tls/openssl.cnf was last modified in September
> 2020 at the time I ran a SCAP Workbench remediation script which modified
> /etc/pki/tls/openssl.cnf to add lines about the Fedora crypto policies.
> /etc/pki/tls/openssl.cnf wasn't updated since then because rpm doesn't
> change config files that don't match those in the update. I moved
> /etc/pki/tls/openssl.cnf to /etc/pki/tls/openssl.cnf.rpmold and moved
> /etc/pki/tls/openssl.cnf.rpmnew from February 2024 to
> /etc/pki/tls/openssl.cnf. I rebooted. kwalletd6 didn't crash when I started
> Proton VPN GUI or logged in using it on the next boot using the new openssl
> config file. The newer openssl config has a section not in the older one
> which shows that the legacy providers are disabled unless certain lines in
> the following are uncommented. 

That's actually the upstream default and is a noop. Can you attach the full cnf
file that triggers the issue?

-- 
You are receiving this mail because:
You are the assignee for the bug.