Контрольные суммы и пределы доверия

SHA-256 отображает последовательность байтов в отпечаток фиксированной длины. При копировании файла сравнение отпечатков помогает обнаружить изменение содержимого. Оно не проверяет, правильные ли строки были выгружены, завершился ли импорт полностью и имел ли отправитель право публиковать данные. Это разные задачи, и для каждой нужен собственный источник доверия.

Если злоумышленник может заменить файл и лежащий рядом checksums.txt, он пересчитает оба. Совпадение после такой замены будет честным, но бесполезным для установления подлинности. Нужен доверенный канал получения отпечатка или проверенная цифровая подпись с известным ключом. Само наличие HTTPS не определяет авторство набора и не заменяет контроль происхождения.

Изменение одного пробела, окончания строки или времени в заголовке gzip меняет отпечаток. Это ожидаемое свойство, а не неудобство алгоритма. Если требуется сравнение значений, сначала определите модель эквивалентности и отдельно вычислите нормализованное представление. Хеш такого представления следует явно отличать от хеша скачиваемого файла.

CRC32 внутри ZIP или gzip предназначен для обнаружения определённых повреждений при передаче и хранении. Он не является криптографической защитой от намеренной подмены. При проверке резервной копии полезны оба уровня: встроенная проверка контейнера и внешний SHA-256. Но даже они вместе не подтверждают, что в архив попали все нужные файлы.

checksums.txt связывает имена с отпечатками. Его относительные пути должны быть однозначными, а команда проверки должна выполняться из указанного каталога. Для собственного каталога загрузок проще использовать ограниченные безопасные имена без переводов строк и обратных слешей. Тогда текстовый список остаётся понятным и стандартные утилиты разбирают его без сюрпризов.

Manifest может дополнительно содержать размер, формат, назначение и версию схемы. Проверяйте согласованность двух представлений: одинаковый набор путей, одинаковые хеши, отсутствие дубликатов. Размер полезен для ранней диагностики обрыва, но не заменяет хеш. При публикации сначала создавайте реальные файлы, затем считайте метаданные именно по итоговым байтам.

Для долговременного архива сохраните manifest отдельно от основной копии и зафиксируйте, когда и кем он был принят. Повторная проверка через год имеет смысл только относительно сохранённого эталона, а не относительно списка, только что пересчитанного по тем же подозрительным файлам. Новый пересчёт полезен как наблюдение, но не доказывает отсутствие прежнего повреждения. При миграции накопителя сначала проверьте исходную копию, затем перенесите данные и сверьте результат с тем же списком. Если обнаружено расхождение, не заменяйте эталон автоматически. Изолируйте различающийся файл, сравните независимую копию и установите причину. Иначе процесс проверки незаметно узаконит повреждение, которое должен был обнаружить до следующей публикации или восстановления.

Для резервной копии базы после проверки SHA-256 выполните открытие только для чтения, integrity_check и несколько предметных запросов. Для CSV проверьте число записей, ширину и типы колонок. Для архива просмотрите список путей до извлечения. Каждый шаг отвечает на отдельный вопрос и не должен объявляться доказательством всех остальных свойств.

Хеширование большого файла выполняйте блоками, не загружая его целиком в память. Во время чтения источник не должен меняться. Иначе отпечаток может описывать последовательность, которая никогда не существовала как завершённая версия. Используйте неизменяемый снимок, блокировку или согласованный механизм резервирования, соответствующий источнику.

В отчёте проверки укажите, откуда получен эталон и что именно совпало. Формулировка «SHA-256 совпал с manifest выпуска» точнее, чем «файл безопасен». Если происхождение эталона неизвестно, честно сохраните это ограничение. Контрольная сумма даёт сильный инструмент проверки целостности, когда известно, с каким доверенным состоянием сравниваются полученные байты.