Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

I expect a discussion about what is working and what is not working with GPGME
and various GnuPG APIs.  I'm just trying to convey my experience with
GnuPG-for-Android, gnupg-for-java, and a little bit with Python.  I hope this
will spur people to offer their experience, and generate new ideas and
approaches.  gpgme-tool is one version of that, `gpg --json` is another.

.hc

Bob (Robert) Cavanaugh:
> Hi Hans,
> Wanted to respond to your post wondering why you are getting the responses you are. 
> 
> In another thread you write:
> "There are other C-Python wrappers of GPGME, like pyme.  I hope you're aware of those, and have studied them.  One thing that GnuPG suffers from is many people starting their own wrappers, but few people finishing them or contributing to existing ones.  That is not a sustainable situation."
> 
> This is the problem. You frame the dialog as blaming GnuPG and the design choices made in its implementation. Direct case in point: It is certainly not Werner's or any other principal GnuPG developer's issue if and when someone else independently took on a project to wrap GnuPG or GPGME. The fact that  these people might have bitten off more than they can chew is completely irrelevant to the canonical implementation and frankly should be irrelevant to this discussion. When I said approach this in a constructive manner I meant this: You have some requirements. In your estimation these requirements are not met with the current toolset. Then instead of explicitly expecting this group to implement a paradigm shift (and forgive me if I misunderstand you, but that is what I infer you are asking for) generate a proposal for an Android-centric API. Or, if you feel that the infrastructure cannot support it, take the completely open sources Werner and group have provided and generate your ow
 n
 system that meets your needs. If possible,  (and here again I am clarifying my original post) work with the people on this group to help you use the existing tools to get your requirements met. But speaking as a professional engineer of 25+ years experience, you will not get your desired results by starting the conversation impuning the work that went before and claiming that what you are asking for is far superior. If it is not your intent to convey that message then please review what you write before you send it, because that message was received loud and clear.
> 
> Thanks,
>  
> Bob Cavanaugh
> 
> 
>> -----Original Message-----
>> From: Hans-Christoph Steiner [mailto:hans at guardianproject.info]
>> Sent: Monday, March 09, 2015 12:08 PM
>> To: Bob (Robert) Cavanaugh; Peter Lebbing
>> Cc: gnupg
>> Subject: Re: Thoughts on GnuPG and automation
>>
>>
>> Why do I get so many responses like this on this list?  I've spent a ton of time
>> solving our own problems with the Android port, we also made sure to take
>> out a support contract with Werner to pay him to answer our questions.  I
>> only wish we'd had more so we could pay him for all the work he has done,
>> but we have long since run out of money for working on GnuPG.  I continue
>> this on my own time because I believe it is important.
>>
>> The point of this discussion is to talk about an shared architecture for using
>> GnuPG outside of C/C++ on UNIX.  That's why Bjarni started it, and that's
>> why I've joined in here.  It seems that half of this thread has been griping
>> about the discussion process.  We need a little more faith in each other so we
>> can have productive discussions and further our shared goals.
>>
>> .hc
>>
>> Bob (Robert) Cavanaugh:
>>> Native to what? Processor, OS?
>>> I think Peter and the group already adequately answered this: If GPGME is
>> not providing an interface that meets Android requirements, then look into
>> how GPGME interfaces to GPG and emulate that interface.
>>> For you to request that the interface be changed can be likened to
>> someone requesting that I2C be changed because you have a hard time
>> implementing it. This is pretty much a non-starter IMHO. Implementing
>> interfaces to existing infrastructures is bread-and-butter to software
>> development. Stop asking for fundamental infrastructure changes and start
>> solving your problem. The group has literally hundreds of m-y that can be
>> used productively to help you do this, but harness the group's power in a
>> constructive manner.
>>>
>>> Bob Cavanaugh
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf
>> Of
>>> Hans of Guardian
>>> Sent: Tuesday, March 03, 2015 3:55 PM
>>> To: Peter Lebbing
>>> Cc: gnupg
>>> Subject: Re: Thoughts on GnuPG and automation
>>>
>>>
>>> On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:
>>>
>>>
>>> In Android, you can't really have shared libraries.  Apps share functionality
>> at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ the
>> shared library in effect, since it provides OpenPGP via Activities.
>>>
>>> No one is saying that each app should have a custom wrapper for GnuPG.
>> What I think mailpile is saying, and what I'm trying to say is that for
>> programming environments where GPGME does not make sense, there
>> should be the ability to easily make a native version of what GPGME is doing.
>>>
>>> .hc
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81