Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Sep 4, 2006, 07:39 UTC
- Message-ID
- <7v8xl0ozbx.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20060904064443.GB30032@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
Show 14 quoted lines
> Junio C Hamano <junkio@cox.net> wrote:
>> Now if we fix dumb transport downloaders, then we could even
>> make a convention that the packs named pack-[0-9a-f]{40}.pack
>> are archive packs. And git-repack can even have a convention
>> that .git/objects/pack/pack-active.(pack|idx) is the active
>> pack.
>
> Seems reasonable.
>
> I take it you are proposing that a dumb transport always downloads
> pack-active.pack as pack-n{40}.pack where the dumb protocol
> downloader computed the correct pack name from its contents. Thus
> any remote pack downloaded over a dumb transport is automatically
> treated as a historical pack by the receiving repository.It is a lot lot lot stronger than that. If the dumb transport (or git in general) uses [0-9a-f]{40} part as the assuarance mechanism to avoid packname collisions, it should be prepared to recompute the correct name for not just pack-acrive but _all_ remote packs and store them under the right name.
Also, if repack uses the convention to treat pack-active.* as the active pack, it might make sense for dumb transport to use that as a clue and explode what the other side calls pack-active.* upon reception. For the purpose of repacking decision for the person at the other end, they are subject for frequent repacking, so maybe we should treat it as such.
Show 8 quoted lines
> [snipped and re-ordered] >> It first downloads the .idx files, so it can compute the >> _right_ packname using the sorted object names recorded there > > Why trust the .idx? I've seen you post that the .idx is purely > a local matter. The "smart" Git protocol only receives the .pack > from the remote and computes the .idx locally or unpacks it to loose > objects locally; why should a dumb transport trust the remote .idx?
Remote .idx is paired with remote .pack and must be able to access into .pack otherwise the remote person could not use the pack locally ;-). Note that we are not talking about malicious repository.
The issue here is not about _trusting_, but adjusting its name to its contents to match your local convention, which is what the recent pack-objects spits out to its standard output. Older versions of pack-objects named the resulting pack with pretty much randomly (it used to use SHA-1 checksum of object names in input order, not in index order which is sorted, so the same pack _could_ have different names), and its output files should be considered valid packs if they are still around.
-- VGER BF report: S 0.999988