Nguyễn Thái Ngọc Duy <[email protected]> writes:
> The idea behind this series is, after add_submodule_odb, odb may have
> new temporary objects that only appear after the call. These temporary
> objects may lead to repo corruption (e.g. some new objects are created
> and point to these temporary objects). This series attempts to catch
> those cases. It would make it safer to dig deeper into submodule's odb,
> e.g. to implement unified git-diff.
>
> Previous approach [1] is record the odb source, then check if the
> source is from submodule's odb. But that means we rely on the
> lookup order in sha1_file.c. This approach instead allows the caller
> to select what odb sources it wants to look up from.
>
> The checks are also less drastic than before. Checks are now done at
> higher level, e.g. commit_tree(), instead of at write_sha1_file,
> because we do allow to write objects that point to nowhere.
>
> Another new thing from previous round is I completely forbid the use
> of add_submodule_odb in security sensitive commands like index-pack or
> rev-list. We could loosen up later if we need to.
>
> For fun, I set object_database_contaminated to 1 by default and ran
> the test suite. It passed :)
How does this interact with alternates set up by the user? It's not
immediately obvious from the commit messages (hint hint) or the comments
near ODB_LOCAL etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
