Libgcrypt and GnuPG libraries in emerge

Andre Heinecke aheinecke at intevation.de
Thu Mar 3 18:55:43 UTC 2016


Hi,

KDE-Windows currently maintains a fork of some GnuPG libraries. The reason for 
this is that the GnuPG maintainer and developers do not want to maintain an 
MSVC build or support compiling on Windows or a CMake buildsystem.

This is partly because of GNU Hackers don't want to care about MSVC or CMake. 
But while I was originally of the opinion that this is wrong I now understand 
that there are real reasons for the decision not to support MSVC or different 
build systems (well not so much about the build systems).

If you look at some of the CVE's affecting libgcrypt like [1][2][3]
you can probably understand that if GnuPG developers say that they need an 
understanding of how their binary code behaves and that they only want to 
maintain that understanding for GCC is not something to be taken as empty 
talk. Can you honestly review their fixes for these issues and say that they 
will also work on MSVC compiled binaries? (Or that there are no other problems 
that were not evaluated by researchers because nearly no one uses MSVC 
compiled libgcrypt)

The added load of maintaining a build system for those libraries (I think I'm 
talking about libassuan, libgpg-error, libgcrypt and gpgme) is imo also not 
something the KDE-Windows community needs.

So, how can we improve the status quo?

My suggestion is that starting with Gpg4win-3.0 as part of the Gpg4win release 
process we provide a "development package". Basically something like [4] but 
always up to date with the latest released Gpg4win version. This release would 
be signed by our publisher key and hosted on the same server as Gpg4win itself 
and would contain the "official" windows binaries that are also published as 
part of Gpg4win. (So that you can report bugs and stuff!) As part of the 
Gpg4win release process I could update the portage script of such a binary 
package.


What's your opinion, would you agree and use such a package?


I know that building from Source is important but in this case upstream just 
does not want to support building from Source on Windows (and especially with 
MSVC).


Regards,
Andre

1: https://www.tau.ac.il/~tromer/handsoff/
2: http://eprint.iacr.org/2013/448
3: http://www.cs.tau.ac.il/~tromer/ecdh/
4: 
https://quickgit.kde.org/?p=emerge.git&a=blob&h=e5bfc9ea283e778570a701064606fc5b4f2386db&hb=11b065758334c6cfaca061cdfbebbaf75b41dd46&f=portage%2Fbinary%2Fgpg4win-e5%2Fgpg4win-e5-20120305.py

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20160303/1ea03ec3/attachment.sig>


More information about the Kde-windows mailing list