- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 19 2025
The problem is that a user may unintentionally use the suggested filename without checking that it does not harm to write to this file. It is better not to present a default name at all.
GPG output seems to depend on Regional Format.
With the next gpg release (2.5.14) the keyboxd has an extended fingerprint table which carries a flags column. A bit in this column can eventually be used to mark subkeys with the "R" key flag and the search funtion can be enhanced to ignore keys with that flag set. This way we can more easily lookup the actual ADSK key (with the "E" key flag) and check whether this subkey has been revoked.
Nov 18 2025
Nov 17 2025
At line 133 shouldn't we have used iobuf_cancel there? Would it be possible to call finish_temp_output from iobuf_close or iobuf_cancel instead?
Nov 16 2025
Fix applied. Thanks.
This is not a composite key specific thing despite that this is an extra challenge. The creation date is used to reconstruct a key if the public key has been lost and only the fingerprint is still available. A solution might be to test the all combinations of stored creation dates to match the fingerprint.
Nov 15 2025
Nov 14 2025
I considered to make the --display argument optional but that still leads to the error. Thus better do not set or send it at all. I did this now for all gpgme engines.
Nov 13 2025
What about adding a "show gnupg log" button as we have in other dialogs?
I am currently working on backup/restore of Kyber keys. The error message will go away.
Nov 12 2025
Nov 11 2025
There are a lot of other ways to confuse the user. We can't fix them all because the whole purpose of a cleartext signature is to make it easy to use in legacy environments like an BBS. Modern systems use MIME to handle this in a more stringent specified way. For any use it is stongly suggested to check the actual signed data which is avaialable with the --output options. At least a sanitizing viewer should be used which filters out all escape characters (something like cat -v |less).
We have seen wrong encodings quite often in the past and thus we won't apply the patch. After all the armor header is a different layer and could also be applied or removed by other software or tools. The integrity of an OpenPGP message does not depend on its concrete outer encoding.
Nov 10 2025
_("Wrongly armored signature\n"));Nov 9 2025
Nov 7 2025
Nov 6 2025
Maybe we should change wipememory to behave like free; ie. ignore a NULL.
Nov 5 2025
Alright, I change it from for notation data (and name).
[GNUPG:] NOTATION_NAME foo@foo.org [GNUPG:] NOTATION_FLAGS 0 1 [GNUPG:] NOTATION_DATA bla%20bla%20��%20blub
with change:
[GNUPG:] NOTATION_NAME foo@foo.org [GNUPG:] NOTATION_FLAGS 0 1 [GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub
Since rfc2440 the PGP specs say:
I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.
Nov 4 2025
We have fixed it but the commit also states:
I agree because the original purpose from the 90ies to enable the use of signed patch files in the Linux kernel community was never actually used and GnuPG stopped the distribution of patches from version to version many years ago. Thus I agree we should hide this option behind a compatibility flag.