Re: Crashes while trying to show tag objects with bad timestamps
- From
Jeff King <peff@peff.net>
- Date
- Feb 25, 2013, 18:21 UTC
- Message-ID
- <20130225182101.GA13912@sigill.intra.peff.net>
- In-Reply-To
- <CAPWNY8UMkxvLPk2TxCz+BAat1sNXitjhv=yqcdY0yZ1OLjgd0w@mail.gmail.com>
On Sat, Feb 23, 2013 at 01:14:40AM +0200, Mantas Mikulėnas wrote:
Show 7 quoted lines
> > Then I think it would make sense to allow the very specific no-date tag, > > but not allow arbitrary crud. I wonder if there's an example in the > > kernel or in git.git. > > I couldn't find any such examples. However, I did find several tags > with no "tagger" line at all: git.git has "v0.99" and linux.git has > many such tags starting with "v2.6.11" ending with "v2.6.13-rc3".
Yes, I think Junio was mis-remembering the exact condition. It looks like we added tagger lines in c818566 ([PATCH] Update tags to record who made them, 2005-07-14), which pulls the identity straight from "git var GIT_COMMITTER_IDENT". I double-checked to be sure that we included the date stamp at that time, and we did.
When parsing such a tag, we put a "0" in the date field of the "struct tag", and I suspect that is what caused the memory confusion.
So I think we are fine to fsck tagger lines as we do ordinary author/committer ident lines; the only exception is that we should not complain if they do not exist.
> It seems that `git cat-file -p` doesn't like such tags too – if there > is no "tagger", it doesn't display *any* header lines. More bugs?
Yeah, I think we should just rid of that parser entirely. It is very inconsistent with the pretty-printer used by "git show", as well as the one used by "git for-each-ref", not to mention parse_tag (ugh, how many tag parsers do we have?).
-Peff