Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1

From: Hans Petter Selasky <hps@selasky.org>
Date: Jan 16, 2023, 14:10 UTC
Message-ID: <31a33eac-5f1b-969a-6e34-2fc18e989293@selasky.org>
In-Reply-To: <017801d929a6$6f8271b0$4e875510$@nexbridge.com>

On 1/16/23 13:31, rsbecker@nexbridge.com wrote:

Show 10 quoted lines

> On January 16, 2023 4:56 AM, Hans Petter Selasky wrote:
>> On 1/16/23 10:13, Michal Suchánek wrote:
>>> when that data is copied to a new location a new CRC is calculated
>>> that can detect an error in that location.
>>
>> Yes, that is correct, but what is "copying data"? Are you saying that copying data is
>> always error free?
> 
> Not in all possible computing devices, no. But in certain high-reliability and mission critical systems, there are parity checks and communication mechanisms that verify the integrity of data transfers memory-to-memory, memory-to-register, and over inter-CPU bus, and memory-to-disk-storage checks. The result of a corruption on one of my systems would result in a CPU halt rather than blindly accepting the result, taking the faulty processor offline until the cause is investigated and then reloaded or repaired. This applies to any component, including disks, CLIMs, DMA, and anything else in the architecture.
>

Hi,

I doesn't matter if the system is high-reliability or not. The problem is exactly the same.

If you have a CPU register which you add to another CPU register, then you need to recompute the parity information on the destination CPU register. That basically means you always trust the output of the CPU adder. There is simply no relationship between input parity and output parity in the linear adder case.

Whenever "parity" information is lost, it opens up the possiblity of irrecoverable errors.

That's why I say, that GIT would be better of in that regard with an end-to-end, CRC parity mechanism.

--HPS