- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 23 2023
For the export of multiple certificates (i.e. not group export), this task is blocked by the wishlist issue T5847: Kleopatra: New Feature for bulk certify. Either this issue is also wishlist or the other issue is needs to become normal.
IMO for LDAP we should not warn at all. Because there it is possible to remove certificates.
In T6637#176910, @fse wrote:OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.
Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).
I opened T6771 for this because this issue is done.
In T6766#177137, @ikloecker wrote:I haven't added the possibility to start a group certification directly from the confirmation message.
In T6767#177126, @werner wrote:Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?
According to Werner this should work.
In high contrast mode the background should always be white or black.
Well, see my very first comment.
Oct 22 2023
Oct 21 2023
Oct 20 2023
That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:
So dirmngr already has that option.
Well, this bug is fixed by using a decent libgpg-error or configure it correctly.
At the moment we have a green background for the results of a decryption and/or verification, if it was successful.
This does not work with high contrast mode.
and it is also confusing that you can choose the key for signing in Kleopatra, it is displayed with a green check mark but then you run into an error:
Oct 19 2023
yes, fixed
I think this was fixed with the fix for https://dev.gnupg.org/T6534
I have added the confirmation to the following commands:
- Export Certificate(s)
- Publish on Server
- Export Group
Oct 18 2023
Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?
Here's a patch that should fix this. It's not amazing since we have to copy the map_w32_to_errno from libgpg-error, as it's not public API there.
You should see
org.kde.pim.libkleo: Reloading keycache with remarks enabled
in the debug output shortly after Kleopatra has finished the initial key listing (even if tags (aka remarks) are disabled in the configuration).
The original issue was to unclear to analyse and it was likely meanwhile fixed. For the other issue see the follow up ticket.
@jukivilli I have addressed a number of your comments now. You find my comments inline.
I mean this would also be solved if we did not use qiodevicedataprovider but pass the filenames directly to gpg for single files, too. (can't remember the ticket number) but I don't want to do that right now.
In T6526#177082, @ikloecker wrote:The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.
That sounds like a solid conclusion. I mean if errno is not set explicitly it is basically undefined which value it is, so maybe some other function set errno to no space left on device in that one case where it "worked".
The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.
I've debugged Eva's problem and I think it's unrelated to the original problem, as it's specific to qt.
Fix was trivial, the classical cancel is not an error problem in the QGpgMEChangeExpiryJob
This has sparked my curiosity.
This happens when cancelling the password entry on normal keys, too. The strange thing is, the changeexpirycommand already checks if "err.isCancelled" and should do nothing in that case.
Tested and there are no available actions. Works.