Как проверить общедоступный исходный код дистрибутива Linux?
Выйдите из системы как этот пользователь, продолжайте работу как root. Создайте указанный дополнительный раздел с помощью fdisk или parted.Создайте временную точку монтирования для этого раздела, скажем, /mnt/tempuser. Смонтируйте его в эту точку монтирования. Rsync /home/$USER в /mnt/tempuser/, а затем mv /home/$USER /home/originaluser. Mkdir /home/$USER и указать его на указанный $USER
Теперь попробуйте войти как $USER. su -$USER, например, из той же корневой консоли. Должно быть достаточно, чтобы проверить, сработало ли это или что пошло не так. Запасной вариант будет
umount /home/$USER ; mv /home/$USER /home/faileduser ; mv /home/originaluser /home/$USER
Затем, если с таким входом все в порядке, добавьте его в /etc/fstab, чтобы он монтировался при загрузке, укажите здесь точку монтирования как /home/$USER
К сожалению, в настоящее время невозможно автоматически сверить выпуск дистрибутива с его исходным кодом. Однако есть промежуточные результаты, которые можно в какой-то степени использовать; проект «Воспроизводимые сборки» является основным драйвером.
Воспроизводимость — это способность при одних и тех же входных данных и одних и тех же инструментах создавать одни и те же выходные артефакты. Таким образом, различные проекты, участвующие в программе воспроизводимых сборок , допускают некоторый уровень воспроизводимости; например:
- многие пакеты Debian воспроизводимы, поэтому при наличии одного и того же исходного пакета и одной и той же среды сборки (компилятора, зависимостей сборки и т. д. )вы получите бит -для -бит идентичных пакетов;
- Официальные образы Docker Debian воспроизводимы , поэтому при наличии тех же эталонных пакетов (, а не исходного кода )и тех же инструментов сборки вы получите бит -для -бит идентичны корневым файловым системам.
Проверка созданных выше артефактов конечным -пользователем пока невозможна, особенно потому, что файлы, в которых записана среда сборки, не опубликованы (, насколько мне известно ). Однако они сохраняются, так что в какой-то момент это станет возможным.
Я не думаю, что какой-либо «большой» дистрибутив поддерживает воспроизводимость на всем пути от исходного кода до дистрибутива (ISO и т. д. ), не говоря уже о проверке. На пути есть ряд препятствий:
- пока не все программы могут быть созданы воспроизводимыми;
- воспроизводимые артефакты включают в себя «знания» о среде их сборки, которые меняются в течение всего времени подготовки дистрибутива (, поэтому проверка дистрибутива потребует реконструкции его истории );
и, вероятно, другие, о которых я сейчас не думаю.Tails действительно публикует полностью -воспроизводимые дистрибутивы, так что это технически возможно, но требует, чтобы дистрибутив был воспроизводим; дистрибутив не может быть проверен внешними субъектами, если он не опубликован воспроизводимым образом. (Это не мешает внешним аудитам существовать и иногда быть полезными.)
Посмотрите на различные проекты , упомянутые на сайте воспроизводимых сборок, некоторые из них сосредоточены на том, чтобы упростить все это; см., например, в -toto . Сам проект Reproducible Builds публикует ряд инструментов , которые могут помочь в создании и анализе воспроизводимых артефактов.
Один пункт в вашем вопросе уже в значительной степени рассмотрен, даже без воспроизводимости и проверяемости:
how can I be sure that the maintainers haven't slipped in something nefarious outside of the public code base during the build?
Большинство дистрибутивов (Не знаю, что такое Deepin )публикуют только бинарные артефакты, созданные на собственной инфраструктуре сборки, поэтому сопровождающие не могут ничего вне общедоступной кодовой базы (public как в записи с артефактом ). Это не отменяет доверия, которое вы неявно оказываете самому дистрибутиву, что является вашей главной заботой здесь, но, по крайней мере, оно лишает отдельных сопровождающих возможности публиковать вредоносные артефакты без публикации соответствующего исходного кода.
См. также классику Кена Томпсона «Reflections on trusting trust », и последующее исследование на тему доверяющих компиляторов ; и следующие вопросы здесь: