Проверяет ли ИСО, загруженную с официального сайта?

Да, ОЧЕНЬ РЕКОМЕНДОВАНО, что вы проверяете загруженное изображение, вот несколько причин:

Если у вас уже есть дистрибутив GNU Linux, вы можете использовать md5sum, если вы в Windows можете использовать: WinMD5Free.

Надеюсь, что это поможет.

Да, но Ubuntu, кажется, делает это сложнее, чем должно быть.

В лучшем случае вы просто загрузите foo.iso и foo.iso.sig и щелкните файл .sig ( или использовать gpg для оболочки в файле .sig) после того, как вы импортировали ключ один раз. Это стоит несколько секунд.

Ubuntu, похоже, усложняет ситуацию, заставляя вас проверять суммы sha256 из файла, пока подписан только сам файл.

С другой стороны, когда файл был сгенерирован только с помощью sha256sum * >SHA256SUMS, вы можете проверить его с помощью sha256 -c и получить OK/Bad/Not-Found в качестве вывода .

Проверьте свой /proc/net/dev и посмотрите, сколько плохих кадров TCP вы получили до сих пор. Если вы видите одноразрядное значение (надеюсь, ноль), читайте дальше. Если у вас есть много или сетевые ошибки, то, во всяком случае, используйте MD5 для проверки ваших загрузок (хотя я бы скорее исследовал основную причину, поскольку ненадежная сеть означает, что вы не можете доверять чему-либо, что вы получаете через HTTP).

Конечно, проверка контрольной суммы все еще имеет значение, охватывающее вас в случаях, когда файл, который вы загружаете, поврежден на сервере, но это происходит не слишком часто.

Как сказал @sudodus в комментариях, использование Bittorrent вместо HTTPS - это еще один вариант, так как торрент-клиенты делают

Обратите внимание, что контрольные суммы на самом деле не мешают вам атаковать, это то, за что HTTPS.

Я нашел трудный способ не проверять суммирование. Я бы сжег компакт-диск с ISO, который был поврежден во время загрузки, и не смог его загрузить, или он имел ошибки при запуске.

Как и другие, это занимает мало времени.

Вы видите это только в одном случае, в настройке с массовой автоматизацией это помогает проверить его; скрипты, которые запускают проверку, прежде чем приступать к тому, что нам нужно делать с изображением

Другие дали ответы с техническими деталями, которые я забыл, хотя я программист (моя работа не связана с сетью через связь), поэтому я просто дам вам знать личный опыт.

Давным-давно, когда я часто записывал компакт-диски, мне однажды пришло в голову загрузить этот дистрибутив Linux, который, как оказалось, загрузился правильно. Мне удалось сменить CD, поэтому я проверил загруженный файл, и он не совпал. Итак, я снова загрузил, и это сработало. Таким образом, это произошло только через 15 лет с тех пор, как я был продвинутым пользователем компьютера и программировал (с компьютеров 11 лет 19 лет назад использовал компьютеры, и я сжег более тысячи дисков). Но это доказательство того, что это может случиться.

Это также случилось со мной через BitTorrent один или два раза, так что это тоже не отказоустойчиво. Когда вы пытаетесь перепроверять загруженный файл, он идентифицировал поврежденный фрагмент.

Мое заключение HTTP (полагаясь на TCP) может быть таким же безопасным, как и в случае с ним, но в Интернете есть промежуточные узлы между вашим устройством и сервер, и нет никакой информации о том, что может произойти на этом пути (пакеты даже теряются все время), и иногда компьютеры не могут сказать, что данные ошибочны, я думаю.

Никто не может ответить будет ли это проблемой для вас - это зависит от контекста, и я уверен, что вы можете судить об этом сами. Для меня это не стоит большую часть времени. Если бы я собирался установить ОС, я бы проверял загруженное изображение раньше.

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

EDIT: У меня даже были другие более опытные программисты, которые работают (с некоторым возмущением), что эти хэши проверки целостности данных позволяют узнать, является ли файл бит-идентичным оригиналу, но я знаю (я читал), что тот факт, что два файла приводят к одному и тому же хэшу, не означает, что они идентичны - это просто означает, что это крайне маловероятно они разные. Способ, которым они полезны, заключается в том, что, когда файлы не идентичны, и особенно когда они сильно отличаются друг от друга, их хэш-коды практически никогда не будут одинаковыми (это даже менее вероятно, что этот тест завершится с ошибкой). В меньших словах - если хэш-коды разные, вы знаете, что файлы разные.

Вы видите это только в одном случае, в настройке с массовой автоматизацией это помогает проверить его; скрипты, которые запускают проверку, прежде чем приступать к тому, что нам нужно делать с изображением

Да, но Ubuntu, кажется, делает это сложнее, чем должно быть.

В лучшем случае вы просто загрузите foo.iso и foo.iso.sig и щелкните файл .sig ( или использовать gpg для оболочки в файле .sig) после того, как вы импортировали ключ один раз. Это стоит несколько секунд.

Ubuntu, похоже, усложняет ситуацию, заставляя вас проверять суммы sha256 из файла, пока подписан только сам файл.

С другой стороны, когда файл был сгенерирован только с помощью sha256sum * >SHA256SUMS, вы можете проверить его с помощью sha256 -c и получить OK/Bad/Not-Found в качестве вывода .

Другие дали ответы с техническими деталями, которые я забыл, хотя я программист (моя работа не связана с сетью через связь), поэтому я просто дам вам знать личный опыт.

Давным-давно, когда я часто записывал компакт-диски, мне однажды пришло в голову загрузить этот дистрибутив Linux, который, как оказалось, загрузился правильно. Мне удалось сменить CD, поэтому я проверил загруженный файл, и он не совпал. Итак, я снова загрузил, и это сработало. Таким образом, это произошло только через 15 лет с тех пор, как я был продвинутым пользователем компьютера и программировал (с компьютеров 11 лет 19 лет назад использовал компьютеры, и я сжег более тысячи дисков). Но это доказательство того, что это может случиться.

Это также случилось со мной через BitTorrent один или два раза, так что это тоже не отказоустойчиво. Когда вы пытаетесь перепроверять загруженный файл, он идентифицировал поврежденный фрагмент.

Мое заключение HTTP (полагаясь на TCP) может быть таким же безопасным, как и в случае с ним, но в Интернете есть промежуточные узлы между вашим устройством и сервер, и нет никакой информации о том, что может произойти на этом пути (пакеты даже теряются все время), и иногда компьютеры не могут сказать, что данные ошибочны, я думаю.

Никто не может ответить будет ли это проблемой для вас - это зависит от контекста, и я уверен, что вы можете судить об этом сами. Для меня это не стоит большую часть времени. Если бы я собирался установить ОС, я бы проверял загруженное изображение раньше.

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

EDIT: У меня даже были другие более опытные программисты, которые работают (с некоторым возмущением), что эти хэши проверки целостности данных позволяют узнать, является ли файл бит-идентичным оригиналу, но я знаю (я читал), что тот факт, что два файла приводят к одному и тому же хэшу, не означает, что они идентичны - это просто означает, что это крайне маловероятно они разные. Способ, которым они полезны, заключается в том, что, когда файлы не идентичны, и особенно когда они сильно отличаются друг от друга, их хэш-коды практически никогда не будут одинаковыми (это даже менее вероятно, что этот тест завершится с ошибкой). В меньших словах - если хэш-коды разные, вы знаете, что файлы разные.

Проверьте свой /proc/net/dev и посмотрите, сколько плохих кадров TCP вы получили до сих пор. Если вы видите одноразрядное значение (надеюсь, ноль), читайте дальше. Если у вас есть много или сетевые ошибки, то, во всяком случае, используйте MD5 для проверки ваших загрузок (хотя я бы скорее исследовал основную причину, поскольку ненадежная сеть означает, что вы не можете доверять чему-либо, что вы получаете через HTTP).

Когда вы загружаете TCP, который контролирует все переданные данные, очень мало шансов иметь коррумпированную загрузку с точно таким же размером. Если вы уверены, что загружаетесь с официального сайта (обычно вы используете HTTPS и пропуски проверки сертификата), проверка того, что ваша загрузка завершена, как правило, достаточно. Достойные веб-браузеры обычно делают проверку для вас в любом случае, говоря что-то вроде строки «загрузка не удалась», если они не получают ожидаемый объем данных, хотя я видел браузеры, которые просто решили сохранить неполный файл, не сказав ничего для пользователя, и в этом случае вы можете проверить размер файла вручную.

Конечно, проверка контрольной суммы все еще имеет значение, охватывающее вас в случаях, когда файл, который вы загружаете, поврежден на сервере, но это происходит не слишком часто.

Как сказал @sudodus в комментариях, использование Bittorrent вместо HTTPS - это еще один вариант, так как торрент-клиенты делают

Обратите внимание, что контрольные суммы на самом деле не мешают вам атаковать, это то, за что HTTPS.

Да, ОЧЕНЬ РЕКОМЕНДОВАНО, что вы проверяете загруженное изображение, вот несколько причин:

Если у вас уже есть дистрибутив GNU Linux, вы можете использовать md5sum, если вы в Windows можете использовать: WinMD5Free.

Надеюсь, что это поможет.

Я нашел трудный способ не проверять суммирование. Я бы сжег компакт-диск с ISO, который был поврежден во время загрузки, и не смог его загрузить, или он имел ошибки при запуске.

Как и другие, это занимает мало времени.

Вы видите это только в одном случае, в настройке с массовой автоматизацией это помогает проверить его; скрипты, которые запускают проверку, прежде чем приступать к тому, что нам нужно делать с изображением

Да, но Ubuntu, кажется, делает это сложнее, чем должно быть.

В лучшем случае вы просто загрузите foo.iso и foo.iso.sig и щелкните файл .sig ( или использовать gpg для оболочки в файле .sig) после того, как вы импортировали ключ один раз. Это стоит несколько секунд.

Ubuntu, похоже, усложняет ситуацию, заставляя вас проверять суммы sha256 из файла, пока подписан только сам файл.

С другой стороны, когда файл был сгенерирован только с помощью sha256sum * >SHA256SUMS, вы можете проверить его с помощью sha256 -c и получить OK/Bad/Not-Found в качестве вывода .

Другие дали ответы с техническими деталями, которые я забыл, хотя я программист (моя работа не связана с сетью через связь), поэтому я просто дам вам знать личный опыт.

Давным-давно, когда я часто записывал компакт-диски, мне однажды пришло в голову загрузить этот дистрибутив Linux, который, как оказалось, загрузился правильно. Мне удалось сменить CD, поэтому я проверил загруженный файл, и он не совпал. Итак, я снова загрузил, и это сработало. Таким образом, это произошло только через 15 лет с тех пор, как я был продвинутым пользователем компьютера и программировал (с компьютеров 11 лет 19 лет назад использовал компьютеры, и я сжег более тысячи дисков). Но это доказательство того, что это может случиться.

Это также случилось со мной через BitTorrent один или два раза, так что это тоже не отказоустойчиво. Когда вы пытаетесь перепроверять загруженный файл, он идентифицировал поврежденный фрагмент.

Мое заключение HTTP (полагаясь на TCP) может быть таким же безопасным, как и в случае с ним, но в Интернете есть промежуточные узлы между вашим устройством и сервер, и нет никакой информации о том, что может произойти на этом пути (пакеты даже теряются все время), и иногда компьютеры не могут сказать, что данные ошибочны, я думаю.

Никто не может ответить будет ли это проблемой для вас - это зависит от контекста, и я уверен, что вы можете судить об этом сами. Для меня это не стоит большую часть времени. Если бы я собирался установить ОС, я бы проверял загруженное изображение раньше.

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

EDIT: У меня даже были другие более опытные программисты, которые работают (с некоторым возмущением), что эти хэши проверки целостности данных позволяют узнать, является ли файл бит-идентичным оригиналу, но я знаю (я читал), что тот факт, что два файла приводят к одному и тому же хэшу, не означает, что они идентичны - это просто означает, что это крайне маловероятно они разные. Способ, которым они полезны, заключается в том, что, когда файлы не идентичны, и особенно когда они сильно отличаются друг от друга, их хэш-коды практически никогда не будут одинаковыми (это даже менее вероятно, что этот тест завершится с ошибкой). В меньших словах - если хэш-коды разные, вы знаете, что файлы разные.

Проверьте свой /proc/net/dev и посмотрите, сколько плохих кадров TCP вы получили до сих пор. Если вы видите одноразрядное значение (надеюсь, ноль), читайте дальше. Если у вас есть много или сетевые ошибки, то, во всяком случае, используйте MD5 для проверки ваших загрузок (хотя я бы скорее исследовал основную причину, поскольку ненадежная сеть означает, что вы не можете доверять чему-либо, что вы получаете через HTTP).

Когда вы загружаете TCP, который контролирует все переданные данные, очень мало шансов иметь коррумпированную загрузку с точно таким же размером. Если вы уверены, что загружаетесь с официального сайта (обычно вы используете HTTPS и пропуски проверки сертификата), проверка того, что ваша загрузка завершена, как правило, достаточно. Достойные веб-браузеры обычно делают проверку для вас в любом случае, говоря что-то вроде строки «загрузка не удалась», если они не получают ожидаемый объем данных, хотя я видел браузеры, которые просто решили сохранить неполный файл, не сказав ничего для пользователя, и в этом случае вы можете проверить размер файла вручную.

Конечно, проверка контрольной суммы все еще имеет значение, охватывающее вас в случаях, когда файл, который вы загружаете, поврежден на сервере, но это происходит не слишком часто.

Как сказал @sudodus в комментариях, использование Bittorrent вместо HTTPS - это еще один вариант, так как торрент-клиенты делают

Обратите внимание, что контрольные суммы на самом деле не мешают вам атаковать, это то, за что HTTPS.

Да, ОЧЕНЬ РЕКОМЕНДОВАНО, что вы проверяете загруженное изображение, вот несколько причин:

Если у вас уже есть дистрибутив GNU Linux, вы можете использовать md5sum, если вы в Windows можете использовать: WinMD5Free.

Надеюсь, что это поможет.

Я нашел трудный способ не проверять суммирование. Я бы сжег компакт-диск с ISO, который был поврежден во время загрузки, и не смог его загрузить, или он имел ошибки при запуске.

Как и другие, это занимает мало времени.