User Details
- User Since
- Mar 27 2017, 4:48 PM (392 w, 3 d)
- Roles
- Administrator
- Availability
- Busy Busy until Sep 9 2030.
Yesterday
Using the shorter OID for v5 is on purpose; thus we need to fix the export.
Tue, Oct 1
Fixed for master. Let's first test this with kleopatra.
Done for 2.2. It is already in 2.4.
Mon, Sep 30
Will be available in 2.2.45 and 2.5.2
No we are at 4 seconds.
Some would say it is a bug if keys are not shown - even if the algo is not known ;-)
Sat, Sep 28
Please send an excerpt from the scdaemon debug output to evaluate why you get somewhat strange looking data. Is this an experimental card? 0xa5 is a common test pattern.
Fri, Sep 27
FWIW, a related task is T7308
With that patch we are down to about 6 seconds.
Will do.
Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.
Something which has high priority but has not been touch can't have a super high priority.
Please write at least a short description and give it a priority
Pretty brief description :-(
Thu, Sep 26
I see only links to our own pages and to the emailselfdefense - which is a good resource.
Hmm, two years old - I doubt that it makes sense to continue here.
Priority lowered in the light of the the forthcoming gpgol.js
Should definitely work with gpg4win if it works with vsd.
A bit more verbose description would be helpful ...
Closing because POP3 is rarely used and has never been supported.
More than a year old - we can reduce the priority.
Note: The code for this is in the work/mmontkowski branch but has not yet been merged with master. Before we take this bug up again, we need to look closer at the ribbon UI events as remarked by Andre on July 29.
That was resolved with vsd 3.2.0
The Libgcrypt version you are using has not been build from git or a released tarballs. Only with a released tarball you would get no suffix. With git bou will see a -betaNNNN suffix.
Backported to 2.2
Wed, Sep 25
I don't think it makes sense to add such a feature/bug fix to the old versions.
We won't do that for Windows.
Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3
Yes, this is a bit annoying but recall that for v3 keys you can't even deduce the keyid from its fingerprint.
I guess this is now fixed for all branches.