It is only used for certificate generation. Use OpenSSL directly.
BUG: 402323
Details
- Reviewers
- None
- Group Reviewers
KDE Connect
Clear config. Pair device, play around
Diff Detail
- Repository
- R224 KDE Connect
- Branch
- noqca
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 7025 Build 7043: arc lint + arc unit
core/kdeconnectconfig.cpp | ||
---|---|---|
198 |
| |
201 | if QSslCertificate::fromPath fails, the return is an empty list, and this will misbehave | |
206 | hint: output the wrong permissions too, so at least the warning gives more clues | |
tests/lanlinkprovidertest.cpp | ||
317 | this can fail, needs error handling | |
318 | this can fail, needs error handling | |
320 |
| |
322 | if QSslCertificate::fromPath fails, the return is an empty list, and this will misbehave | |
tests/testsslsocketlinereader.cpp | ||
287 | this can fail, needs error handling | |
289 | this can fail, needs error handling | |
291 |
| |
293 | if QSslCertificate::fromPath fails, the return is an empty list, and this will misbehave |
Using the command line tool means this is a runtime dependency only. You could run kdeconnect without having openssl installed and it would fail mysteriously.
We can either check that it exists and output a specific error, or change to a compile-time dependency (libopenssl? Not sure if it exists).
I'm not sure I'm understanding the conversation. The library is called libssl. It's apparently a little complicated to use, but there is a good StackOverflow example of how it is done: https://stackoverflow.com/questions/256405/programmatically-create-x509-certificate-using-openssl
I think using the library is a better solution than running a command line utility and hoping it will be installed/perform as expected.
Please do not use libcrypto/libssl directly:
- it does not have a stable ABI
- its API changes often too
- its license is not exactly nice, imposing extra clauses on what uses it; see https://www.openssl.org/docs/faq.html#LEGAL2 and https://people.gnome.org/~markmc/openssl-and-the-gpl.html (and they will switch soon to Apache 2.0)
To get to the point of this patch: what is the problem it is trying to solve?
The linked bug (402323) just mentions a generic failure, when loading a certificate via QSslCertificate::fromPath() on macOS. Was any debugging done to know why?
Thanks for the info! We wanted to rid of QCA because it's a rather big library and it gave us some problem with the Windows and Mac ports. We only use it to generate a certificate the first time kdeconnect runs, so any library that can do that would work for us.
I added some checks, though I'm not sure what excactly should happen in case the generation fails.
Do we really need the error handling for the tests?
I split the generation from loading, to a separate function and added some error checks if the key can't be loaded, is empty, etc.
Let's discuss at the sprint?
Have you considered what it would look like using libssl.so directly?
Is this good to ship?
Since there is a dylib duplicated link error caused by qca-qt5 on macOS(when we use Craft to pack KDE Connect with qml files), this will be helpful for all qml apps we have up to now :)
I think at the sprint we decided we didn't want to use OpenSSL. It has licensing problems when using the library directly and using the binary seems like it could lead to problems with multi-platform packaging and with the potential for the command-line flags to change in the future. We talked about looking at GnuTLS but nobody has done that yet.
What problem are you having? It seems weird that you would only be having a problem with QML applications now since there are already several, like the SMS app and the settings app and since none of them use QCA
It's described here: https://invent.kde.org/snippets/336
I talked it with Hannah. If we won't port away from qca-qt5, I'd like to fix it in Craft as what I've done in my local env :)
According to https://github.com/openssl/openssl/issues/9426 the library should have a stable ABI. Maybe what you told us is outdated?