Thoughts on GnuPG and automation

[Bob (Robert) Cavanaugh]

If that is the goal, that is a fair one.

Thanks,
 
Bob Cavanaugh


> -----Original Message-----
> From: Hans-Christoph Steiner [mailto:hans at guardianproject.info]
> Sent: Monday, March 09, 2015 2:22 PM
> To: Bob (Robert) Cavanaugh; Peter Lebbing
> Cc: gnupg
> Subject: Re: Thoughts on GnuPG and automation
> 
> 
> 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