Re: Submodules and SHA-256/SHA-1 interoperability

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi brian,

On Sat, 13 Mar 2021, brian m. carlson wrote:

> On 2021-03-01 at 19:28:13, Johannes Schindelin wrote:
> > While my strong urge is to add "Remove support for submodules" (which BTW
> > would also plug so many attack vectors that have lead to many a
> > vulnerability in the past), I understand that this would be impractical:
> > the figurative barn door has been open for way too long to do that.
> >
> > But I'd like to put another idea into the fray: store the mapping in
> > `.gitmodules`. That is, each time `git submodule add <...>` is called, it
> > would update `.gitmodules` to list SHA-1 *and* SHA-256 for the given path.
> >
> > That would relieve us of the problem where we rely on a server's ability
> > to give us that mapping.
>
> This is true, but it ends up causing problems because we don't know
> where the .gitmodules file is for a given revision.  If we're indexing a
> pack file, we lack the ability to know which .gitmodules file is
> associated with the blobs in a given revision, and we can't finish
> indexing that file until we have both hashes for every object.
>
> While we could change the way we do indexing, we'd end up having to
> crawl the history and that would be very slow.

Hrm, that's a valid point.

I just wish that we could make this more independent of servers. There
_might_ be a way to work around the flaw you pointed out, e.g. adding the
mappings from `.gitmodules` to the repository-local SHA-1 <-> SHA-256
mapping. But maybe somebody else can think of a better way?

Ciao,
Dscho