Today
Wed, Feb 20
Mon, Feb 18
Fri, Feb 15
Thu, Feb 14
Thanks for that summary.
Wed, Feb 13
Since it seems there is a renewed interest in adding ECC support to GpgSM (as indicated by the T4098 feature request), I would like to write down here more details about this task.
Tue, Feb 12
Pinentry already has a ttyalert option which may be set to beep or flash to ring the bell or flash the terminal, respectively (see commit 1dba96fafa123f3631c0a50bb01835306c23b903).
Mon, Feb 11
Sat, Feb 9
Sure, but lets use that ticket for this. if you have another topic, feel free to open another ticket.
Thu, Feb 7
Wed, Feb 6
Wed, Jan 30
Tue, Jan 29
Good idea.
Mon, Jan 28
for user ID selection, you could also potentially match on substring, so uid dkg could select/deselect all user IDs that contain "dkg".
Fri, Jan 25
Wed, Jan 23
Mnemonics can be made language independent by implementing wordlists for every language. In bip39, each word represents a number, 0 through 2047 (their index in the wordlist).
Jan 7 2019
Dec 20 2018
Dec 18 2018
Dec 17 2018
How scdaemon responds when there is no card available?
Dec 15 2018
Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:
Dec 13 2018
yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.
Dec 12 2018
The --auto-expand-secmem option is available in 2.2. and master for quite some time. It works if libgcrypt 1.8.2 or newer is used.
Dec 11 2018
Will go into 2.1.12 to be released next week.
Dec 10 2018
Dec 8 2018
Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.
Dec 5 2018
That is good.
Just a heads up to everyone, Fedora is moving forward with this change for Fedora 30 (currently rawhide). https://bugzilla.redhat.com/show_bug.cgi?id=1656282 is the bug tracking it.
Dec 4 2018
Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.
Just to stress it; I am in favor of allowing builds using other compilers. We allow this on Unix and so we should allow this on Windows as well. We should remember to use different DLL names to make it explicit that a certain DLL is targetting a specific ABI.
Another build systems does not solve your problem. If you want to support another toolchain, that is fine. But it can as well be done with the current build system. it is a matter of adding a new platform triplet to make sure we are not linking against different libc versions. In fact we can build all our code on a wide range of platforms with very different compilers, so supporting MSVC won't be a problem. Mixing them is a bad idea as can be shown by the usual cross-runtime malloc/free problems.
Dec 3 2018
Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(
I give this high priority. This blocks for years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC (you can say that this is bad, but it is a fact of life). As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.