Hi Peter, I took a look at that library a while back but it's not that great. The problem is that to write a really good GnuPG library, you need to use the --status-fd and parse that to get signer information and other useful tidbits that you simply cannot get by using gpg in the way that the biko library does.
For example, when you want to verify a pgp signature, you want more than a true/false (biko gives you pass/fail via an exception or not) - you want to programmatically be able to know which signatures failed, why, who the signer was, etc. I've written IPC to GnuPG before, here: https://git.gnome.org/browse/gmime/tree/gmime/gmime-gpg-context.c#n594 You'll notice that the information I provide back to the caller is substantially more than what the biko gpg wrapper provides and I feel that the info I provide in my GMime library is the bare *minimum*. Honestly, if you want to use a GnuPG library, then I'd recommend using one that wraps libgpgme (such as https://github.com/danm-de/gpgme-sharp). Unfortunately, libgpgme is not available on iOS or Android (nor is gpg) and on Windows, it is only available in 32bit mode, which means the C# app has to target the 32bit .NET runtime instead of the 64bit runtime. I suspect that in the future, there will be a 64bit port of libgpgme, but even then you'll have to make a choice between 64bit and 32bit. We are sadly in a world where 64bit hasn't quite taken over completely and 32bit is still prevalent enough that we, as programmers, need to support it. The beauty of BouncyCastle's OpenPGP implementation, in my eyes, is that it is not tied to 32bit vs 64bit or any particular processor architecture. Now, of course, that can all fall apart if it doesn't actually work or if it's buggy to the point of not being able to interoperate with gpg and other pgp implementations. I don't know if it is or isn't. I suspect it works, but if development has stalled and the OpenPGP implementation is unmaintained, then it might not be viable because, as other implementations mature and/or bugs are found, if they don't get fixed, I'm going to want to move into something else. That's part of what I'm hoping to find out. Hope that makes sense, Jeff On Fri, Oct 25, 2013 at 4:44 AM, Peter Lindgren <[email protected]>wrote: > Hi! > > Jeff Stedfast skrev 2013-10-25 04:25: > > Sadly, C# APIs do not provide a nice way >> to do IPC with programs like gnupg, so my options are limited if I want >> portability... again leading me to BouncyCastle for the OpenPGP >> implementation. >> > > There's a C# library available at https://biko.codeplex.com/ that > communicates with GnuPG4Win using streams and std in/out. I've uploaded > some small patches there, however no response so far. > > I'm not a crypto expert, so I cannot judge neither code nor developers > from a security perspective, but since GnuPG4Win is the official port for > Windows and it appears more active than BouncyCastle, my humble opinion is > that GnuPG4Win is a safer bet when it comes to discovering and plugging > security holes. This is *not* personal to all you developers, it's only how > it appears from the outside without having done a security review. > > /Peter > -- > Peter Lindgren > Norrsken konsult > [email protected] > 0703-393940 > >
