Согласен, дописал в конец статьи совет пользоваться только репозиториями (официальными, т.к. сторонний репозиторий тоже нужно проверять перед добавлением) в случае отсутствия полного понимания у человека.
Насчет мартышкиного труда не согласен, но я согласен что лучше искать по запросу вида «packagename sha1» или подобного. И конечно проверять подпись, если она есть.
Для того, чтобы проверка чексуммы стала полностью бесполезной, необходимые условия такие:
— взломан сервер на котором лежит программа;
— подменены чексуммы во всех других местах.
А если взлом произведен недавно? А если взломано только зеркало? Должно выполниться больше условий для того, чтобы в итоге запустился вредоносный код.
Итог — проверка хэшей и поиск их в гугле безусловно полезна, вопрос только в том, насколько. Безопасность же это не все или ничего, это не черно-белая штука, можно только увеличить ее с некоторой вероятностью.
Неверно. В репозиториях Ubuntu и пакеты подписаны, но ключа на них самих нет, ключ есть только на сборочных серверах. Так работает защита в глубину, система разделяется на части и между ними ставятся перегородки.
Если репозиторий или зеркало взломать, пакеты подписать все равно не получится, и apt-get не даст поставить пакет с неправильной контрольной суммой, т.к. в списке пакетов, подписанным в свою очередь закрытым ключом, которого в репозитории тоже нет, контрольная сумма указанна другая другая, а у нового подмененного файла со списком пакетов подпись не совпадет.
Матчасть полезно знать. Теперь вы видите отличия от HTTPS, которое гарантирует только защищенное соединение точка-точка, и иногда подлинность сервера с котором вы соединяетесь, но ничего больше.
Поэтому кстати зеркала можно http отдавать без опасений.
HTTPS выполняет совершенно другую задачу, он не дает вообще никаких гарантий по поводу содержания. Это разные задачи, они по разному решаются.
Ну и что, что сертификат валиден? А если сервер сломали? Еще и не у таких ломали, вспомните фиаско с взломом kernel.org. В том случае кстати все получилось легко исправить только потому, что был инструмент, git, который работал с контрольными суммами.
Если можете просмотреть код и убедиться, то спокойно можно скачивать. Если нет, лучше брать релиз. Обратите внимание, что в этой штуке в конце вшита куча сертификатов, это видимо значит, что сама эта штука все проверяет как положено.
Но после ctrl+d у вас отвалится сессия и спасет только перезагрузка и загрузочный образ или колдовство с grub (можно ли замонтировать файловую систему так, чтобы все файлы были исполняемыми, как в vfat?). Или у вас есть какой-нибудь особенно хитрый способ?
Это отвратительно. Как напоминает капитан очевидность, безопасность и удобство находятся на разных концах одной и той же палки, и абсолютная безопасность недостижима, но отказываться от разумных действий вовсе? Остается только надеяться, что несколько раз нарвутся и прекратят.
Более простое состоит в использовании busybox или другого прелоадера, который тоже может оказаться в системе, вы это конечно знаете.
С использованием чистого баша я не знаю, как можно проще решить задачу «скопировать один бинарный файл в другой бинарный файл», к которой сводится задачка из статьи. Если придумаете — будет круто :)
Audit trail не предлагать, можно удобно логировать с привязкой к пользователю.
— взломан сервер на котором лежит программа;
— подменены чексуммы во всех других местах.
А если взлом произведен недавно? А если взломано только зеркало? Должно выполниться больше условий для того, чтобы в итоге запустился вредоносный код.
Итог — проверка хэшей и поиск их в гугле безусловно полезна, вопрос только в том, насколько. Безопасность же это не все или ничего, это не черно-белая штука, можно только увеличить ее с некоторой вероятностью.
Это не дает полной гарантии, как и любое аналогичное действие, но значительно лучше, чем ничего.
Если репозиторий или зеркало взломать, пакеты подписать все равно не получится, и apt-get не даст поставить пакет с неправильной контрольной суммой, т.к. в списке пакетов, подписанным в свою очередь закрытым ключом, которого в репозитории тоже нет, контрольная сумма указанна другая другая, а у нового подмененного файла со списком пакетов подпись не совпадет.
Матчасть полезно знать. Теперь вы видите отличия от HTTPS, которое гарантирует только защищенное соединение точка-точка, и иногда подлинность сервера с котором вы соединяетесь, но ничего больше.
Поэтому кстати зеркала можно http отдавать без опасений.
Ну и что, что сертификат валиден? А если сервер сломали? Еще и не у таких ломали, вспомните фиаско с взломом kernel.org. В том случае кстати все получилось легко исправить только потому, что был инструмент, git, который работал с контрольными суммами.
Но я код не читал, могу ошибаться.
Если у вас нет выбора и нужно ставить, делайте так:
А потом вот так: www.google.ru/search?q=df1001975035f07d09307bf1f1e62584
С использованием чистого баша я не знаю, как можно проще решить задачу «скопировать один бинарный файл в другой бинарный файл», к которой сводится задачка из статьи. Если придумаете — будет круто :)
У меня было заготовлено очень похожее решение:
Оно работает немного быстрее, но я его не полностью сам придумал, мне немного подсказали джедаи баша. Так что вам полное ура!
Но зачастую, как сказал nazarpc, запускать ничего и не надо. Достаточно браузером открыть скрипт, и вручную поставить нужные пакеты.