Libgcrypt and GnuPG libraries in emerge

Cristian Oneț onet.cristian at gmail.com
Tue Jun 14 10:52:53 UTC 2016


I failed to add, please let us know when the "development package"
will be available.

2016-06-14 12:49 GMT+02:00 Cristian Oneț <onet.cristian at gmail.com>:
> Hi Andre,
>
> I just discussed this with Hannah at Randa and we both agree that your
> proposal of using gpg4win prebuilt binaries is the best option. I will
> work on making this happen.
>
> Regards,
> Cristian
>
> 2016-03-03 19:55 GMT+01:00 Andre Heinecke <aheinecke at intevation.de>:
>> 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
>> _______________________________________________
>> Kde-windows mailing list
>> Kde-windows at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-windows
>>


More information about the Kde-windows mailing list