Re: Stable GnuPG interface, git should use GPGME

On Thu, 23 Mar 2017 08:29, bernhard.rei...@intevation.de said: > I was under the impression (and I do remember you telling me a few times) > that the output of the command line interaction did change a lot over times > and using applications had issues. I've experienced a few of those over the

Re: Stable GnuPG interface, git should use GPGME

On Wed, 22 Mar 2017 19:46, pe...@digitalbrains.com said: > under the impression you are actually answering the question "can GPGME > be used in the same way regardless of the GnuPG version" instead? Right. > 3) is because GnuPG 1.4 cannot update a secret key at all. Adding a new > subkey fails

Re: Stable GnuPG interface, git should use GPGME

Am Mittwoch 22 März 2017 18:15:36 schrieb Werner Koch: > On Fri, 17 Mar 2017 10:56, bernhard.rei...@intevation.de said: > > As the command line is not a stable API to GnuPG, there were changes and > > there will be changes to the command line over several versions. It maybe > > in the > > That is

Re: Stable GnuPG interface, git should use GPGME

On 22/03/17 18:15, Werner Koch wrote: > It actually does. For the tasks git uses gpg you should not notice a > difference in gpgme between any of these versions. Bernhard wrote "interoperability problems between [...] key stores". I'm under the impression you are actually answering the question

Re: Stable GnuPG interface, git should use GPGME

On Fri, 17 Mar 2017 10:56, bernhard.rei...@intevation.de said: > As the command line is not a stable API to GnuPG, there were changes and > there > will be changes to the command line over several versions. It maybe in the That is not true. The command line interface has been stable for the

Re: Stable GnuPG interface, git should use GPGME

Am Dienstag 14 März 2017 11:39:12 schrieb Michael J Gruber: > >> The problem is the "difficult" upgrade path and mixed installations with > >> gpg and gpg2.1+ that some distributions force upon you: > >> > >> As soon as you start gpg2.1, your (secret) key store is migrated to a > >> new format

Re: Stable GnuPG interface, git should use GPGME

Bernhard E. Reiter venit, vidit, dixit 13.03.2017 13:49: > Am Montag 13 März 2017 11:14:57 schrieb Michael J Gruber: >> Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23: >>> On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter > please consider using libgpgme interfacing to

Re: Stable GnuPG interface, git should use GPGME

"brian m. carlson" writes: > Because the amount of the gpg API we actually use is very small, a user > who wants to use a custom signature program (say, OpenBSD's signify), > can actually write a simple wrapper that mimics it and use that instead. FWIW, I did this,

Re: Stable GnuPG interface, git should use GPGME

On Mon, Mar 13, 2017 at 12:14:17PM +0100, Bernhard E. Reiter wrote: > Using a completely different OpenPGP implementation maybe a potential use > case > for keeping a configuration option around. I did not deeply examine what git > really needs. Usually a different implementation will have

Re: Stable GnuPG interface, git should use GPGME

Am Montag 13 März 2017 11:14:57 schrieb Michael J Gruber: > Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23: > > On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter > >> please consider using libgpgme interfacing to GnuPG, because the gpg > >> command-line interface is not

Re: Stable GnuPG interface, git should use GPGME

Am Samstag 11 März 2017 01:10:31 schrieb brian m. carlson: > On Fri, Mar 10, 2017 at 11:00:07AM +0100, Bernhard E. Reiter wrote: > > but even better would be to move to libgpgme. >:) > > There are a couple potential problems I see with this approach. First, > I'd want to know whether gpgme

Re: Stable GnuPG interface, git should use GPGME

Am Freitag 10 März 2017 19:54:19 schrieb Linus Torvalds: > On Fri, Mar 10, 2017 at 2:00 AM, Bernhard E. Reiter > > please consider using libgpgme interfacing to GnuPG, because the gpg > > command-line interface is not considered an official API to GnuPG by the > > GnuPG-devs and thus potentially

Re: Stable GnuPG interface, git should use GPGME

Am Freitag 10 März 2017 15:23:27 schrieb Ævar Arnfjörð Bjarmason: > On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote > > please consider using libgpgme interfacing to GnuPG, because the gpg > > command-line interface is not considered an official API to GnuPG by the > > GnuPG-devs and

Re: Stable GnuPG interface, git should use GPGME

Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23: > On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter > wrote: >> Dear Git-Devs, > > I haven't contributed to Git's GPG code, but I'm taking the liberty of > CC-ing some people who have. > >> git uses

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 11:00:07AM +0100, Bernhard E. Reiter wrote: > My use case today was signing and git by default found the `gpg` binary by > default and the command failed. The reason is that I have `gpg2` installed > and most applications use it right away. So git failed signing because >

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 10:54:19AM -0800, Linus Torvalds wrote: > - library versioning. > >I don't know why, but I've never *ever* met a library developer who > realized that libraries were all about stable API's, and the library > users don't want to fight different versions. Actually, you

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 2:00 AM, Bernhard E. Reiter wrote: > > git uses an pipe-and-exec approach to running a GnuPG binary > as writen in the documentation [1]: > > gpg.program >Use this custom program instead of "gpg" found on $PATH when making >

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote: > Dear Git-Devs, I haven't contributed to Git's GPG code, but I'm taking the liberty of CC-ing some people who have. > git uses an pipe-and-exec approach to running a GnuPG binary > as writen in the

Stable GnuPG interface, git should use GPGME

Dear Git-Devs, git uses an pipe-and-exec approach to running a GnuPG binary as writen in the documentation [1]: gpg.program Use this custom program instead of "gpg" found on $PATH when making or verifying a PGP signature. The program must support the same