The patch to the specs would be this:
The three data items hashed for document signatures need to - mirror the values of the Literal Data packet. For detached - and cleartext signatures 6 zero bytes are hashed instead. + mirror the values of the Literal Data packet. Note that for a + detached signatures this means to hash 6 0x00 octets and for a + cleartext signature this means to hash a 't' followed by 5 0x00 + octets.
Regading your first point: From gnupg (2.4) sign.c:hash_sigversion_to_magic
werner do you have any idea based on the information from the original report where we could start looking for this?
I also see this from time to time, mostly when the keyring is empty or very small. But never was able to reproduce it. I thought this might be fixed with keyboxd but if you say that scdaemon might be the culprit then I might misunderstood the issue and it is not the keyring loading that is stuck but maybe rather our configuration initialization which queries the config of each component and is also part of the "Loading certificate cache.."
Thank you. I think it is good that we have now the time to attack some of these more difficult problems :) I don't understand the code there so don't expect a review from me.
Oh wait. That shows a Problem in our side. We should include the full chain in our signature. I am renaming your task and will at least investigate if we do or if that maybe changed the last time we updated the certificate. Which might have been after 4.0.3
I agree that "Delete All" should use the same list of attachments as "Save All". Additionally, we should make sure that in both cases the list of attachments that are saved/deleted is identical to the list of attachments that is displayed as attachments in the viewer. Hopefully, KMime::Message::attachments() is also used for this.
There's also https://bugs.kde.org/show_bug.cgi?id=351426 that argues for a full GUI to allow the user to individually select attachments to delete. I can think of such a GUI but I think the amount of work needed to implement it would not be justified by the rather niche use-case.
OK, had to install the intermediary CA certificate from https://support.globalsign.com/ca-certificates/intermediate-certificates/code-signing-standard-ev-intermediate-certificates . For some reason it was missing from my system.
After installing things look good.
The setting which I understood to be the workaround:
Should be fixed.
Phew! This bug has been with us for more than 20 years unless gpg's behaviour has changed only later.
Using -o signedtext.txt fixes the problem. Unfortunately, gpgme does
err = add_arg (gpg, "--output");
if (!err)
err = add_arg (gpg, "-");
[...]
if (!err)
err = add_data (gpg, plaintext, 1, 1);i.e. it tells gpg to write the output to stdout and then reads everything from stdout as plaintext.
In the group dialog I can not cycle forward with Tab endlessly through the not-greyed-out buttons of the window because the focus gets stuck in the bottom row. There "Revert" is included in the cycling, which is not correct, since it is greyed out. With Shift+Tab, cycling backwards works as expected.
On windows the main window looks ok with high contrast mode black. But with dark backgrounds some items in other windows are not readable:
The error was changed to "Bad data" which should be more appropriate.
In T6617#173396, @werner wrote:What we have here is a clear text signature followed by a public key. If you run this with
gpg -o signedtext.txt --status-fd 2 signedtext.txt should only receive "bar" and not the key listing. If that is not the case something would be very wrong.
This works on Linux with KMail and with Claws (although with Claws the attachment is added twice).
works on windows, too
This issue should be tested together with T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.
I have also further unified the handling of the expiration date when