Today
Yesterday
The problem with Enter has been fixed upstream. I have added a patch with this fix.
This is caused by a bug in gpgsm. The card serial numbers are missing in the with-colon key listing.
This here is resolved, for timegrids findings see other ticket, the issue is not related to the one from this ticket and no regression, as it turned out.
Maybe we should change wipememory to behave like free; ie. ignore a NULL.
That's my mistake with KEM API.
Here is my idea to implement the feature:
(1) Extend struct iobuf_struct to have a field of temporary output (of int), just after real_fname.
- OUTPUTFILE: When it's 1, a file generated with real_fname original suffix removed and appended .tmp is used for the output
(2) Modify get_output_file in plaintext.c and make_outfile_name in openfile.c, so that OUTPUTFILE above is used and the field in iobuf_struct is marked.
(3) Modify proc_encrypted in mainproc.c so that rename .tmp file to the OUTPUTFILE or remove it when failure.
Applied to 1.11 branch.
Let me explain the background.
Wed, Nov 5
@gniibe Thanks for the detailed reply. Looks like we were lucky to hit v2.5.12 when building our CI containers few weeks ago, rebuilding those now with 2.5.13 fixed the problem. Thanks again!
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
Thanks for clarification. I added this to the doc enhancement ticket https://dev.gnupg.org/T7911 and set this ticket to invalid.
Test with beta32
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.
I think this is a matter of imprecise documentation.
So, for the current vsd docs (3.3): https://gnupg.com/vsd/kleopatra-settings.html
This would be more correct, if i understood it right?
HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra HKEY_CURRENT_USER\Software\Wow6432node\GNU\Kleopatra
My point about action restrictions was to add one sentence in the docs section to clarify, what exactly is restricted then.
I think there is a misconception about Action Restrictions. Yes, they exclusively disable the corresponding action, i.e. the action is hidden and the keyboard shortcuts won't do anything. Action restrictions are no means to disable certain functionality as a whole like "Add User ID". Just because somebody listed all available actions in the documentation (which is rather questionable in my opinion) doesn't mean that it makes sense to remove those actions. Maybe only relevant/important actions should be listed so that the readers are not drowned in a huge list of largely irrelevant settings.
For settings in VSD 3.x best look at https://dev.gnupg.org/source/kleo/browse/gpg4win%252F24.05/src/kcfg/settings.kcfg (gpg4win/24.05 branch).
This looks questionable:
HKEY_LOCAL_MACHINE\Software\Wow6432node\GNU\Kleopatra HKEY_CURRENT_USER\Software\GNU\Kleopatra
Either both keys use the 32-bit compatibility path Wow6432node\ or both keys don't. 32-bit builds (like VSD 3.x) will use the compatibility path (without being aware of the redirection). 64-bit builds (like Gpg4win 5.x) don't use it. Since Windows mirrors some settings between both registry paths it may not matter.
Allright, then the dash notation for those two groups are intended and the documentation needs to be adjusted
I suspect that the author of the documentation confused the (internally used) "name" of the settings with the "key" that's used in the config files (and the registry). For reference: Many settings are defined in https://dev.gnupg.org/source/kleo/browse/master/src/kcfg/settings.kcfg .