On 9.8.2018 20:40, Junio C Hamano wrote:
> Jeff King writes:
>
>> I guess leaving it serves as a sort of cross-check if gpg would return a
>> zero exit code but indicate in the status result that the signature was
>> not good. Sort of a belt-and-suspenders, I guess (which might not be
>> that
On Thu, Aug 09, 2018 at 11:40:27AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] gpg-interface: propagate exit status from gpg back to the
> callers
>
> When gpg-interface API unified support for signature verification
> codepaths for signed tags and signed commits in mid 2015 at
On Thu, Aug 09, 2018 at 11:40:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I guess leaving it serves as a sort of cross-check if gpg would return a
> > zero exit code but indicate in the status result that the signature was
> > not good. Sort of a belt-and-suspenders, I guess
Jeff King writes:
> I guess leaving it serves as a sort of cross-check if gpg would return a
> zero exit code but indicate in the status result that the signature was
> not good. Sort of a belt-and-suspenders, I guess (which might not be
> that implausible if we think about somebody wrapping gpg
On Thu, Aug 09, 2018 at 08:30:25AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There was a patch at the start of this thread, but it specifically
> > checks for "sigc->result == U". That's probably OK, since I think it
> > restores the behavior in earlier versions of Git. But I
Jeff King writes:
> There was a patch at the start of this thread, but it specifically
> checks for "sigc->result == U". That's probably OK, since I think it
> restores the behavior in earlier versions of Git. But I wonder if we
> should simply be storing the fact that gpg exited non-zero and
On Thu, Aug 09, 2018 at 01:43:02AM +, brian m. carlson wrote:
> On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote:
> > "brian m. carlson" writes:
> >
> > >> FWIW, I'm on board with returning non-zero in any case where gpg would.
> > >
> > > I think that's probably the best
On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> >> FWIW, I'm on board with returning non-zero in any case where gpg would.
> >
> > I think that's probably the best solution overall.
>
> FWIW, I am not married to the current behaviour. I would
"brian m. carlson" writes:
>> FWIW, I'm on board with returning non-zero in any case where gpg would.
>
> I think that's probably the best solution overall.
FWIW, I am not married to the current behaviour. I would not be
surprised if it mostly came by accident and not designed.
> There's a
On Wed, Aug 08, 2018 at 07:04:56PM -0400, Jeff King wrote:
> On Sat, Aug 04, 2018 at 10:43:46AM +0200, Karel Kočí wrote:
> > I have a solution for my problem (calling git verify-* twice and grep).
> > That is
> > not the point of this email nor this contribution. The point is that
> > although
>
On Sat, Aug 04, 2018 at 10:43:46AM +0200, Karel Kočí wrote:
> > I think the only sensible thing is to err on the conservative side, and
> > return non-zero if we saw _any_ invalid signature.
> >
> > I will note, though, that just checking the exit code of `verify-tag`
> > isn't really that
On Fri, Aug 03, 2018 at 12:06:34PM -0400, Jeff King wrote:
> On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:
>
> > > This is not a deviation. GPG correctly recognizes difference between
> > > trusted,
> > > untrusted and unknown levels. git on the other hand does not. Well it
Santiago Torres writes:
> Now that I think about it though, verify tag can verify more than one
> tag. I assume that this would make it difficult to propagate individual
> errors in trusting. I honestly don't know what's the best way to modify
> this behavior then.
I am not sure if changing the
On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:
> > This is not a deviation. GPG correctly recognizes difference between
> > trusted,
> > untrusted and unknown levels. git on the other hand does not. Well it did
> > until
> > the commit a4cc18f29. That one removed GPG exit code
> > disable fetching keys from hkp servers. This way signature verification
> > should fail.
> >
> > Thanks,
> > -Santiago.
>
> This is not a deviation. GPG correctly recognizes difference between trusted,
> untrusted and unknown levels. git on the other hand does not. Well it did
> until
> the
On Tue, Jul 31, 2018 at 08:25:47PM -0400, Santiago Torres wrote:
> On Wed, Aug 01, 2018 at 12:19:42AM +, brian m. carlson wrote:
> > On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> > > Hello,
> > >
> > > me and my colleague are struggling with automation of verifying git
>
On Wed, Aug 01, 2018 at 12:19:42AM +, brian m. carlson wrote:
> On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> > Hello,
> >
> > me and my colleague are struggling with automation of verifying git
> > repositories and we have encountered that git verify-commit and
> >
On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> Hello,
>
> me and my colleague are struggling with automation of verifying git
> repositories and we have encountered that git verify-commit and
> verify-tag accepts untrusted signatures and exit successfully.
I don't have
Hello,
me and my colleague are struggling with automation of verifying git
repositories and we have encountered that git verify-commit and
verify-tag accepts untrusted signatures and exit successfully.
We have done some investigation of the GPG verification changes in git
repository which I
19 matches
Mail list logo
