On Mon, May 08, 2023 at 09:38:56PM +0000, brian m. carlson wrote:
On 2023-05-08 at 02:00:56, Felipe Contreras wrote:
brian m. carlson wrote:
> On 2023-05-02 at 23:46:02, Felipe Contreras wrote:
> > In my view one repository should be able to have part SHA-1 history,
> > part SHA3-256 history, and part BLAKE2b history.
>
> That is practically very difficult and it means that it's hard to have
> confidence in the later history because SHA-1 is weak and you have to
> rely on it to verify the SHA-256 history later.
Why would I have to rely on SHA-1 to verify the SHA-256 history later
on?
If your history contains mixed and matched hash algorithms, you'll need
to be able to verify those commits to the root to have any confidence in
a signed commit or tag, which means trusting SHA-1 if you have any SHA-1
commits in the repository.
the history is traversed from the end anyway, so having sha-1 in the
history is entirely irrelevant for verifying sha-256 commits, assuming
one may only upgrade the algorithm.
the transition plan implies the intent to ultimately get rid of old
algos, but this is a non-starter, because old histories need to remain
accessible indefinitely (you can't rewrite all external references, and
even for in-history references this would be unreliable and would
falsify historical builds).
i won't try making an argument for mixed histories, as i'm assuming i
wouldn't add anything that hasn't already been written.
-- ossi
