On Tue, 3 Sep 2013, Duy Nguyen wrote: > On Tue, Sep 3, 2013 at 1:30 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Tue, 3 Sep 2013, Duy Nguyen wrote: > > > >> On Tue, Aug 27, 2013 at 11:25 AM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > >> > This goes as follows: > >> > > >> > - Tree reference: either variable length encoding of the index > >> > into the SHA1 table or the literal SHA1 prefixed by 0 (see > >> > add_sha1_ref()). > >> > > >> > - Parent count: variable length encoding of the number of parents. > >> > This is normally going to occupy a single byte but doesn't have to. > >> > > >> > - List of parent references: a list of add_sha1_ref() encoded references, > >> > or nothing if the parent count was zero. > >> > >> With .pack v3 it's impossible to create delta cycles (3b910d0 add > >> tests for indexing packs with delta cycles - 2013-08-23) but it is > >> possible with .pack v4 (and therefore at least index-pack needs to > >> detect and reject them), correct? Some malicious user can create > >> commit A with parent ref 1, then make the SHA-1 table so that ref 1 is > >> A. The same with the new tree representation. > > > > pack-index should validate the SHA1 of the object being pointed at. > > > > In that case I doubt you'll be able to actually construct an object > > which contains a SHA1 parent reference and make the SHA1 of this very > > object resolve to the same value. > > We could do that for commits. For trees, we need to look at the base's > content to construct the current tree and cycles could happen. I think > we could make a rule that base trees must appear in the pack before > the tree being constructed (similar to delta-ofs). The exception is > objects appended for fixing thin pack. I don't really like such artificial constraints. You never know when such constraints are going to prevent future legitimate pack layout optimizations or the like. It is simple enough to detect cycles during delta validation in index-pack anyway. Nicolas -- 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