Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> Currently, there is no easy way to verify push certificates. They have
> the same structure as signed tags: "attached detached signatures", that
> is: the concatenation of the signed material and its detached signature.
>
> Introduce a `--blob` option to verify-tag so that it allows to verify
> tags and blobs.
>
> Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>
> ---
> The first outcome of my long announced project to describe our signature
> formats in Documentation/technical.... (progress underway)
>
> In fact, that whole area is in need of refactoring: gpg related bits are
> all over the place, including tag.c. The proposed patch neither improves
> nor worsens the situation in that respect. But, since we make it
> unnecessarily hard to verify signatures (git cat-file | gpg --verify fails)
> it's only fair to provide a tool for pre-receive hook writers.
Another (orthogonal) thing to think about is "is it sensible to add
a new feature to verify blob objects that has signature?"
That is, if we are adding one new feature, isn't it more sensible
for it to accept a stream of bytes from the standard input and run
verify-signed-bufter on it? That way, if you already happen to have
a blob, you can feed it "cat-file blob" output to get the new
feature you added in this patch.
But you cannot go in the other direction without incurring downside.
If you start from "verify signature in blob" interface, and if all
you have is a log of push certificates in a flat text file [1], you
would need to do "hash-objects -w" first only to be able to use that
interface (which in turn means that you would need write access to
the object store of the repository.
[Footnote]
*1* push certificate is first written as a blob in the object store
only so that we can safely run multiple receive-pack instances
without them stepping on each others' toes; it is expected that
they are collected by the server operator in chronological order
and published in a human readable log form, so that outside
people can verify honesty of the server operator.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html