Re: commit-message attack for extracting sensitive data from rewritten Git history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 08, 2013 at 08:40:36AM -0700, Junio C Hamano wrote:

> With or without the security issue, leaving old object names that
> will become irrelevant in the rewritten history will make the
> resulting history less useful, simply because people cannot look at
> the objects these messages refer to. The same argument is behind the
> reason why "cherry-pick -x" was originally the default, found to be
> a mistake and made optional.
> 
> filter-branch provides "map" helper function to help mapping old
> object names to rewritten object names, but stops there; it leaves
> it up to the message filter script to identify what string in the
> message is an object name to be rewritten.
> 
> It can be taught to be more helpful to the message filter writers,
> and you seem to have done so in BFG, which is very good.

Yeah, it would make sense for filter-branch to have a "--map-commit-ids"
option or similar that does the update. At first I thought it might take
two passes, but I don't think it is necessary, as long as we traverse
the commits topologically (i.e., you cannot have mentioned X in a commit
that is an ancestor of X, so you do not have to worry about mapping it
until after it has been processed).

-Peff
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]