Re: [Ksummit-discuss] [TOPIC] Metadata addendum to git commit

[Christian Couder <chriscool@tuxfamily.org>]

From: Jason Cooper <jason@lakedaemon.net>

> On Sun, May 18, 2014 at 09:23:15PM +0200, Christian Couder wrote:
>> From: Takashi Iwai <tiwai@suse.de>
> ...
>> > I tried a hackish way once ago: keeping simple text files named with
>> > $SHAID in a separate branch, and refers to it at git log or bisect
>> > time.  There must be much elegant way, I suppose, though.
>> 
>> Yeah, using "git replace" is more elegant. And there will be hopefully
>> soon the --edit option that will make it very easy to use git replace.
> 
> Yikes.  Sorry, but I don't like that at all.  I hope that feature is
> disabled by default (git replace).

By default replace refs are not fetched and not pushed. So you only
have the replace refs you created yourself on your own repo. They are
only fetched or pushed if you use or configure a refspec like
'refs/replace/*:refs/replace/*'.

You can also use the GIT_NO_REPLACE_OBJECTS environment variable or
"alias git='git --no-replace-objects'", if/when you want to make sure that
replace refs are not used.

A hook could also check that for example each replace ref you add to
your repo replaces a commit with another commit that points to the
same tree.

You could also use 2 different repos, one where you do most of your
work and don't have any replace ref, and one where you do your
bisecting and where you have replace refs. You can create, fetch and
push replace refs in your bisecting repo.

> I guess my first question is: Does the PGP signature verification of a
> signed tag fail if there are replaced commits in the history?

First any kind of Git object can be replaced, not just commits, even
tag objects. Also I think the PGP signature verification only checks
the content of the tag for signed tags or the content of the commit
for signed commits.

So it might be a good idea to disable replace refs (for example using
the GIT_NO_REPLACE_OBJECTS environment variable or
--no-replace-objects) when you want to check signatures, and maybe Git
could warn or error out if the commit or tags that are being verified
are replaced.

But if you have replace refs and some blobs or trees are replaced, you
have to trust these replace refs. (And maybe you are very right to
trust them because for example you created them yourself and never
fetched any replace ref.)

Anyway maybe we should cc Junio and other people on this because
signing is not a part of Git that I know well.

> And if
> so, is that a cryptographic failure, or a logical failure?

I don't think there is any failure.

Some things are inherently risky. For example if you bisect kernels,
you might compile and run kernels that have known security bugs, so
you have to be careful.

Best,
Christian.