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 thorough. It shows that there was _a_ signature, but
> > we don't know:
> >
> > - if it was an identity the user would expect to be signing tags
> >
> > - if it even matches the refname we used to find the tag
> >
> > So I'd argue that any real verification needs to either have a human in
> > the loop, or implement a custom policy based on reading the full output.
> >
> > I know we (and you specifically Santiago) talked about this a while ago,
> > and we ended up providing ways to get more information out of
> > verify-tag, so that a tool could sit on top of that and implement more
> > project-specific policy. I don't know offhand of any reusable tools that
> > do so, though.
>
> I think that it would be even legit to exit on first tag verification
> failure. If
> someone wants to really verify all tags then it can be done with simple for
> loop.
> git that way does not have to solve problem of error combination.
Yeah, I'd be fine with that.
> > - if it was an identity the user would expect to be signing tags
> That can be done just by using trust levels.
I may be showing my PGP cluelessness here, but I thought trust levels
were about saying "to what degree do I think this uid matches this key".
Or are you proposing feeding gpg a fixed trust-db pre-seeded with keys
that are allowed to sign?
I suppose that would work, but:
- is it much easier than just verifying the uid from gpg output
against a trusted list?
- it mixes authentication and authorization. I.e., you lose the
ability to know about a case of "yes, this signature is valid by
this person, but they are not an authorized tagger".
Definitely for some use cases that is fine (and easier still is to just
not even have disallowed keys in your keyring). But I don't think it's a
general solution.
> > - if it even matches the refname we used to find the tag
> Can you explain this more? You mean that string (such as v1.1) used to lookup
> tag
> object is not verified as part of that object?
Yes. The signature is just over the tag object contents itself. That
object does contain a "tag" field, but it may or may not be the tag
you're expecting. Git _could_ confirm that when you looked up a tag via
refs/tags/v1.1 that the tag object we found has "tag v1.1" in it. But
that's not always possible (you might feed Git a resolved name, for
example).
> OK I thing that it was enough of abstract concepts from me. Let me explain you
> what am I trying to achieve. I am implementing feeds (in other words git
> repositories with packages) and package sources verification for OpenWRT. We
> (project Turris by CZ.NIC) are signing all our commits and all our tags. Now
> we
> are using small script that is verifying our repositories just before we run
> build. That is against keyring maintained on our server. I am trying to extend
> that to whole OpenWRT tree. That introduces problem of having a lot of keys
> and a
> lot of packages sharing same allowed keys. Fetching all allowed keys for every
> package from key servers is just slow because of that I have to share those
> between packages. In general there are two options. First one is to have
> cache of
> already fetched keys in armor format. Second one is to have one keyring and by
> setting all keys explicitly as never trusted with package given exception.
> Unfortunately first option can't be used because of one other request that is
> from
> our team. We don't want to be forced to update list of allowed contributors
> to our
> projects every time we have new colleague. Solution we come up with is to have
> central PGP key that signs our whole team and then verification is done by
> allowing GPG to fetch additional keys with max-cert-depth 1. That brings me
> to git
> verify-commit/tag that won't exit with zero code when signature is not
> trusted.
OK, that makes some sense (and I guess answers my "how would you use the
trustdb" question above).
> 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
> GPG's behavior of exiting with 0 code when trust level is unknown is
> unexpected
> but in the end understandable, git's behavior of exiting with 0 code even if
> key
> is explicitly untrusted is just counterintuitive. I think that few people are
> still going to get nasty surprise when I consider that this change was
> introduced
> mid 2014 just after v2.4.0 and Ubuntu 14.04 lts (running even on part of our
> infrastructure) still contains version 1.9.1 and in that release it was
> acknowledging GPG exit code.
FWIW, I'm on board with returning non-zero in any case where gpg would.
-Peff
