- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 5 2023
In T6328#166678, @aheinecke wrote:@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.
For now that we do not want to push for more WKS support with gpgcom, as this will depend on adoption of WKS. So I am resolving this issue.
Since the issue T6328 described an issue with high pirority which would be fixed by this issue I am raising the prio here.
@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.
We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.
My understanding is that: selftest in Kleo does call assuan_socket_connect (possibly in kleopatra/src/libkleopatraclient/core/command.cpp), and it didn't send nonce correctly.
Jan 4 2023
Thanks! I don't understand why your fix helps as Kleopatra never calls assuan_socket_connect on the server side, but it helps. :) So this is probably called indirectly and I don't see it.
We can simply change the arg type from number to string and use a value like 3072/20240101
Yes this is windows. With the USB Stick I think it makes it more reproducable that bytesToWrite will return something. We also had reports that this happened on Network drives so its probably just "some added delay or something where the Windows Kernel does not do buffering".
The first thing I noticed is that ProcessStdInOutput uses redirect_close<QProcess> as process class. redirect_close overrides QProcess::close, but it never calls the original close(). That's very dubious. Maybe it's not a problem, but there's no comment explaining why the original close() doesn't need to be called. Or maybe that's what is causing the hang in waitForFinished.
I found an issue in the assuan code of client side. This might be the cause of the server failure for nonce.
Jan 3 2023
The followup of this issue for libassuan is: https://dev.gnupg.org/T6324
Hello Andre Heinecke,
I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.
So the problem is occuring when the output is finalized (which happens after the GpgME Decrypt Result is signalled). And when there are still bytes to write in line 332 https://dev.gnupg.org/source/kleo/browse/master/src/utils/output.cpp$332
What I mean is that our socket emulation is encapsulated in libgcrypt and details should not be visible to the caller. Further libassuan and kleopatra might be build against different libc versions and thus the used structures might also differ.
As you might have seen from the commits mkportable has been removed from Gpg4win.
From the NEWS assuan_sock_set_sockaddr_un was only added in 2014, years after the UIServer code was really last modified.
Jan 2 2023
I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.
The question is why Kleopatra does not use assuan_sock_set_sockaddr_un as we do in GnuPG. See for example
https://dev.gnupg.org/source/gnupg/browse/master/kbx/keyboxd.c$1124 - was this a workaround back when we had no support for Unicode? assuan_sock_set_sockaddr_un and assuan_sock_get_nonce work together and their internal workings should be opaque to the caller.
Btw. This is how Kleopatra creates the socket: https://dev.gnupg.org/source/kleo/browse/master/src/uiserver/uiserver_win.cpp$34 which does not use a function that would set is_socket=1. My naive fix would be:
My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".
o.O have overlooked this since October.
This is most likely caused by an incompatible addon. See: https://wiki.gnupg.org/GpgOL/IncompatibleAddons
If no keyserver is configured GnuPG uses its default keyserver. "disable-dirmngr" would be the option to completely disable keyserver access but that is rarely used.
I think the current way is a good compromise. Turning this into a fatal error has also resulted in very many support cases.
On Windows, a whitespace character followed by a number in parenthesis at the end of the file name is now stripped from the proposed output file name.
Jan 1 2023
Dec 31 2022
Dec 30 2022
Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.
Dec 29 2022
Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.
@ikloecker Well in the spirit of user friendlyness Kleo could assist the user by removing this added blurb. We already assist the user in using a different folder then the temporary folder for such files.
Dec 28 2022
Hello Andre Heinecke,
Dec 27 2022
This is probably not the right place, but considering you're telling people *here* that they should not build in the source tree, your README and INSTALL files do tell the users to do exactly that.