- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Yesterday
Thu, Oct 31
My fault: All my test had the relax flag set which is so common to me that I did not thought about this. So you fix is for the case that no flag has been set for a fingerprint.
(Please don't set a milestone tag for a fix to an already released version - we use the milestones to track done tickets). Use instead the branch specific tag so it ends up on the workboard.
Wed, Oct 30
I reviewed this and there are actually two changes. The first chnage
is a simple string change from
Sorry, I don't understand your problem. Please explain what you did and what the (perceived) problem is. BTW, GnuPG 2.3.4 is a very old version.
Tue, Oct 29
You should use gpg-agent's integrated ssh-agent. It is anyway much more convenient. I'll move this task to gnupg26, though.
Backported to 2.4 to go into 2.4.6
Was fixed in master with rG374195e741cf1c52daad6c07799d308c8a9f73e3 (bug tag was missing in the commit).
Fix backported to 2.4
Alright, finally supported by gpgme (fot 1.24) For testing you may use
Thus the rule is that all our Qt applications except for pinentry need to fist initialize gpgme to get the actually used GNUPGEHOME. gpgconf either takes this from the GNUPGHOME envvar or from its default or via its gpgconf.ctl file.
The latter can eventually be used to move the default homedir to %APPDATA%\gnupg-vsd so to allow using different versions of the gnupg engine.
Mon, Oct 28
Indeed, gpg fixes a long standing bug in that expired trusted-keys were not correctly handled. Thus this error message
Fri, Oct 25
If we fix this bug for 2.2 we need to have a configure way to revert to the old behaviour. That needs to be a kleopatra config. Or we just don't fix this bug for current vsd but only for gpg4win and the next generation vsd.
Solved for gnupg 2.2, 2.4 and 2.6. GPGME support still missing.
Thu, Oct 24
iirc, Kleopatra modifies the trustlist.txt on its own. The import case is handled by gpgsm which pops up boths dialogs.
Kleopatra should also not offer to add a root CA if gpg-agent's mark-trusted feature has been disabled.
Wed, Oct 23
Also done for gpgsm in gnupg26 (master)
Tue, Oct 22
The C comittee is getting more an more absurd by adding new keywords. Breaking software for fun and funding. Workaround should be easy: Don't use the C23 option.
What about the simplification below. Add more authors and sort-lines as you like. There is no legal necessary to show a full list of copyright holders. Authors are not a legal term in the context of software because software is not considered a piece or art. From the GNU coding standards related to the version/about output:
See T7255 instead.
Mon, Oct 21
Fri, Oct 18
Tue, Oct 15
There is no such concept of a primary keyblock for a subkey. Using the same subkey for several primary keys is non frequent but nevertheless seen use-case. Thus this behaviour is not ADSK specific. I would suggest to first search the keyblock used for decryption to get the name of another subkey - only if that is not found search the keyring for that subkey and thus the primary key and its user id.
FWIW, the cache has not been implemented in 2.4 (which will be used for the next gpg4win) and thus there is no need for a fix there.
Was fixed last Thursday with commit rG69a8aefa5bf77136b77383b94e34ba784c1cce89 for 2.2 and will soon make it to master.
Mon, Oct 14
It is not of the recipient's business to know which certificate also uses a subkey. For all the user needs to know that it is a subkey which belongs to a primary key. In this regard this is not different from a shared encryption subkey as used by many sites for role addresses. For a subkey the user id of its primary should always been show.
Sun, Oct 13
Yes. I think that Kleo does not yet fully support the R-flag indicating an ADSK.
Fri, Oct 11
$ echo -n _gpgrt_spawn_actions_set_envchange | wc -c 34
systemd based Linux?