Tue, Jun 4
Mon, May 27
Thu, May 23
May 18 2019
FWIW, I disabled @aa7356 because he again started to troll.
Snap question regards to the clock;
May 17 2019
May 14 2019
I anyway plan to extend the --quick-gen-key parameters to allow the specification of several subkeys on the command line.
May 9 2019
May 2 2019
Users keep showing up in our support, confused by this inconsistency. here's the most recent ones:
Apr 30 2019
Apr 5 2019
I did lot of tests in the last weeks while working on gpg-card.
Well, it took long to fix. My original plan was to fix it while reworking getkey.c but that I have not yet come to work on that.
Apr 3 2019
This is largely solved.
Apr 1 2019
Mar 23 2019
fwiw, a comment over on T4422 contains a bash script that tries to force GnuPG to do its certificate/signature re-ordering. this doesn't produce anything canonical yet, but it's the closest i've come so far to getting GnuPG to do something repeatable with a certificate after merging (but even that is not quite stable).
Mar 21 2019
Mar 18 2019
Mar 14 2019
The issue for the quality indication is: T2103
FWIW I like @gouttegd 's patchset.
Mar 8 2019
I reviewed the multibyte handling in GnuPG and you are right, there is a general problem because we use ReadConsoleA and basically GetCommandLineA, so there is no way for multibyte input unless a parameter file is used. Output is also broken, but that is easier to fix iff the input case has been fixed.
Mar 7 2019
Changes backported to 2.2
Mar 6 2019
Thanks for fixing that.
That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.
Feb 26 2019
Builds fine now with GCC 9. Thanks for looking into this so quickly.
Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.
Fixed in master, by removing use of compound literals. Compound literals are not portable feature (even for C99 code), so, it's good to avoid when we can.
Still dns.c uses C99 features of struct initializer with name.
Feb 18 2019
Libdns is not our own code and our intention was to keep it in sync with upstream. However, after some initial success the upstream author lost interest. We now consider to rework the code to remove a bit of the more creative use of C99 and maybe even get rid of some of the used C99 features (gnupg is mainly C90 with some exceptions).
Feb 11 2019
I can't tell whether this bug report is about all the ways that we wish that GnuPG's default password process was better, or whether it's about one specific change.
Regarding the quality evaluation, several months ago I proposed to optionally delegate that task to an external tool (specified by a new gpg-agent option passphrase-checker). I posted a first draft as D442 and then submitted a proper patchset to gnupg-devel, but although @werner expressed interest it was never merged. I have just checked that the patchset still applies cleanly to both the master branch and the STABLE-BRANCH-2-2. I can re-submit it to the mailing list if needed.
Feb 4 2019
First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.
Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.