Использование менеджеров пакетов Debian

[Rootlexx]

Rootlexx
не вышло

Вывод покажите.

[sunny1983]

Код: Выделить всё

iskatel@gate:/srv/adminfiles$ equivs-build --arch i386 etersoft-bung
dpkg-architecture: предупреждение: указанный GNU тип системы i486-linux-gnu не совпадает с gcc типом системы x86_64-linux-gnu, попробуйте задать правильное значение в переменной окружения CC
dh_testdir
dh_testroot
dh_prep
sh: 1: cannot open package: No such file
sh: 1: defaults: not found
dh_prep: rm -f debian/<package name; defaults to equivs-dummy>.*.debhelper returned exit code 127
make: *** [install] Ошибка 25
Error in the build process: exit status 2

Кстати после выполнения equivs-control должен был каталог debian появляться? Так его нет.

[Rootlexx]

Кстати после выполнения equivs-control должен был каталог debian появляться?

Нет.
Вы точно не забыли вставить etersoft-bung в поле Package:?

[sunny1983]

А теперь так:

Код: Выделить всё

iskatel@gate:/srv/adminfiles$ sudo dpkg --install etersoft-bung_1.0_i386.deb
Выбор ранее не выбранного пакета etersoft-bung.
(Чтение базы данных … на данный момент установлено 61717 файлов и каталогов.)
Распаковывается пакет etersoft-bung (из файла etersoft-bung_1.0_i386.deb) …
Настраивается пакет etersoft-bung (1.0) …
iskatel@gate:/srv/adminfiles$ sudo dpkg --install haspd_3.3-eter5debian_i386.deb
(Чтение базы данных … на данный момент установлен 61721 файл и каталог.)
Подготовка к замене пакета haspd 3.3-eter5debian (используется файл haspd_3.3-eter5debian_i386.deb) …
Распаковывается замена для пакета haspd …
dpkg: зависимости пакетов не позволяют настроить пакет haspd:
 haspd зависит от libncurses5.

dpkg: ошибка при обработке параметра haspd (--install):
 проблемы зависимостей — оставляем не настроенным
Обрабатываются триггеры для man-db …
При обработке следующих пакетов произошли ошибки:
 haspd
iskatel@gate:/srv/adminfiles$ sudo dpkg --install haspd-modules_3.3-eter5debian_i386.deb
(Чтение базы данных … на данный момент установлен 61721 файл и каталог.)
Подготовка к замене пакета haspd-modules 3.3-eter5debian (используется файл haspd-modules_3.3-eter5debian_i386.deb) …
Распаковывается замена для пакета haspd-modules …
dpkg: зависимости пакетов не позволяют настроить пакет haspd-modules:
 haspd-modules зависит от haspd, однако:
  Пакет haspd пока не настроен.

dpkg: ошибка при обработке параметра haspd-modules (--install):
 проблемы зависимостей — оставляем не настроенным
При обработке следующих пакетов произошли ошибки:
 haspd-modules

[Rootlexx]

Вот и отлично, трюк сработал. Теперь выполните apt-get -f install, которая должна предложить установить libncurses5:i386.
И ещё кое-что: вы всякий раз заново устанавливаете пакеты haspd и haspd-modules, хотя они уже установлены (распакованы), просто не до конца (не настроены). apt-get сам выполнит их настройку, когда все зависимости будут удовлетворены.

[QWERTYASDF]

А как-то можно посмотреть man доступного в репозитории пакета?

[Rootlexx]

А как-то можно посмотреть man доступного в репозитории пакета?

Есть manpages.debian.net.

[QWERTYASDF]

Есть несколько разнородных вопросов, напишу их сразу в одном сообщении.

Параметры системы

Код: Выделить всё

cat /etc/apt/sources.list

Spoiler

# Официальный репозиторий Debian
deb http://ftp.ru.debian.org/debian wheezy main contrib non-free
deb-src http://ftp.ru.debian.org/debian stable main contrib non-free
# Debian Wheezy - обновления
deb http://ftp.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ wheezy-updates main contrib non-free
# Debian Wheezy - обновления безопасности
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
# Debian Wheezy - proprsed - updates
deb http://ftp.ru.debian.org/debian/ wheezy-proposed-updates main
deb-src http://ftp.ru.debian.org/debian/ wheezy-proposed-updates main
# Debian Wheezy - backports
deb ftp://mirror.mephi.ru/debian wheezy-backports main contrib non-free
deb-src ftp://mirror.mephi.ru/debian wheezy-backports main contrib non-free
# Зеркала
deb ftp://ftp.ru.debian.org/debian/ stable main contrib non-free
deb-src ftp://ftp.ru.debian.org/debian/ stable main contrib non-free
deb ftp://debian.nsu.ru/debian/ stable main contrib non-free
deb ftp://ftp.corbina.net/debian/ stable main contrib non-free
deb http://debian.chuvsu.ru/debian/ stable main contrib non-free
deb ftp://ftp.psn.ru/debian/ stable main contrib non-free
deb http://mirror2.corbina.ru/debian/ stable main contrib non-free
deb http://mirror.yandex.ru/debian/ stable main contrib non-free
# Мультимедиа
deb http://www.deb-multimedia.org testing main non-free
# MAN
deb http://manpages.ylsoftware.com/debian/ all main

deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official i386 DVD Binary-1 20130615-21:54]/ wheezy contrib main
deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official i386 DVD Binary-2 20130615-21:54]/ wheezy contrib main
deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official i386 DVD Binary-3 20130615-21:54]/ wheezy contrib main
deb cdrom:[Debian GNU/Linux 7.1.0 Update DVD 20130616: i386 DVD 1]/ wheezy contrib main non-free

Код: Выделить всё

uname -a

Spoiler

Linux localhost-name 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686 GNU/Linux

Код: Выделить всё

cat /etc/debian_version

Spoiler

7.1

Вопросы

1. Насчет реализации безопасности использования репозиториев при помощи gpg-ключей/подписей. Насколько я пока сумела понять, производится аутентификация как минимум репозитория следующим образом:

-Мой локалхост берет открытый ключ этого репозитория, которым шифрует что-то неизвестное больше никому.
-Репозиторий расшифровывает посылку своим закрытым ключом и отсылает назад.
-Локалхост проверяет ответ и в случае совпадения считает репозиторий подлинным.

Это так?

2. Какие есть варианты реализации получения открытых ключей? Как понимаю - получение с помощью соответствующего сервера ключей, либо установка специального пакета с архивом ключей? Есть какие стандарты или неформальные нормы для URI данных серверов? Ну например, откуда мне брать ключи для ftp://ftp.ru.debian.org/debian/ stable или deb http://manpages.ylsoftware.com/debian ?

3. При apt-get update мне в конце выдаются такие строчки:

Код: Выделить всё

W: Ошибка GPG: [url="http://ftp.ru.debian.org"]http://ftp.ru.debian.org[/url] stable Release: Следующие подписи неверные: BADSIG 8B48AD6246925553 Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@debian.org>
W: Ошибка GPG: [url="ftp://ftp.ru.debian.org"]ftp://ftp.ru.debian.org[/url] stable Release: Неизвестная ошибка при выполнении gpgv

Это значит? Либо ложный репозиторий (что маловероятно), либо поменялся его открытый ключ, либо что еще? Если нужно новый ключ, то таки как получить?

4. Ну и наверное самый важный вопрос касательно обновления моей системы. Я ее собираюсь обновлять путем:

Код: Выделить всё

apt-get upgrade

или

Код: Выделить всё

apt-get dist-upgrade

На данный момент уже (или еще...) не понимаю разницы между ними, что лучше использовать? Ну и вообще, какие дадите рекомендации? Ведь система то год не обновлялась...

[Hephaestus]

-Мой локалхост берет открытый ключ этого репозитория, которым шифрует что-то неизвестное больше никому.
-Репозиторий расшифровывает посылку своим закрытым ключом и отсылает назад.
-Локалхост проверяет ответ и в случае совпадения считает репозиторий подлинным.

Это так?

По-моему там всё проще гораздо.
Файлы в репозитории имеют цифровые подписи (подписаны закрытым ключом). Локалхост имеет возможность проверить эту цифровую подпись (с помощью открытого ключа). Вот и всё. Ничего "неизвестного" шифровать и пересылать нет нужды.

Какие есть варианты реализации получения открытых ключей? Как понимаю - получение с помощью соответствующего сервера ключей, либо установка специального пакета с архивом ключей? Есть какие стандарты или неформальные нормы для URI данных серверов? Ну например, откуда мне брать ключи для ftp://ftp.ru.debian.org/debian/ stable или deb http://manpages.ylsoftware.com/debian ?

Это где как. В Slackware, к примеру, открытый ключ можно стянуть прямо с официального сайта.
В Debian-multimedia прежде чем пользоваться репозиторием предлагают установить пакет с ключами.
В официальном Debian, вроде бы тоже - пакет называется debian-keyring. В описании пакета debian-keyring есть ещё ссылка на http://keyring.debian.org/

На данный момент уже (или еще...) не понимаю разницы между ними, что лучше использовать?

Вот что говорит man apt-get

upgrade
upgrade используется для установки новейших версий всех установленных пакетов системы из источников, указанных в /etc/apt/sources.list. Будут разысканы новейшие версии установленных в настоящий момент пакетов и произведено обновление; ни в коем случае не будет удалено ни одного установленного пакета или установлено нового пакета, не имеющего уже установленной в системе предыдущей версии. Текущие версии установленных в настоящий момент пакетов, если они не могут быть обновлены новыми версиями без изменения статуса других пакетов, будут оставлены в неизменном виде. Для того, чтобы apt-get узнал о существовании доступных новых версиях пакетов, данной команде должна предшествовать команда update.

dist-upgrade
dist-upgrade, в дополнение выполняет функцию upgrade, а также разумно управляет изменением зависимостей с новыми версиями пакетов; apt-get имеет "умную" систему разрешения конфликтов и она будет в случае необходимости пытаться произвести обновление наиболее важных пакетов за счет менее важных. Файл /etc/apt/sources.list содержит список источников для получения пакетов, из которых будут получены файлы пакетов.

Лучше, чем здесь, я всё равно не изложил бы.

При apt-get update мне в конце выдаются такие строчки

Попробуйте для начала поставить свежую версию этого самого debian-keyring (может быть даже скачав его вручную), а там видно будет.

[sgfault]

-Мой локалхост берет открытый ключ этого репозитория, которым шифрует что-то неизвестное больше никому.
-Репозиторий расшифровывает посылку своим закрытым ключом и отсылает назад.
-Локалхост проверяет ответ и в случае совпадения считает репозиторий подлинным.

Это так?

По-моему там всё проще гораздо.
Файлы в репозитории имеют цифровые подписи (подписаны закрытым ключом). Локалхост имеет возможность проверить эту цифровую подпись (с помощью открытого ключа). Вот и всё. Ничего "неизвестного" шифровать и пересылать нет нужды.

Вот картинка с цепочкой доверия:

Код: Выделить всё

D = distribution (suite (stable, ..), codename (squeeze, ..)
C = component (main, ..)
B = architecture 'binary-architecture'
S = architecture 'source'
<-- means, that file on the left contains hash or sign of file on the right.
hash is md5, sha1, sha256.
sign is sign with Debian Archive key.

                                              +-----D/C/B/Packages <--hash-- .deb
                                             /  +-- D/C/B/Release
                                            /  /
D/Release.gpg <--sign-- D/Release <--hash--+--+
                                            \  \
                                             \  +-- D/C/S/Sources <--hash-- .dsc, .tar.gz, .diff.gz
                                              +---- D/C/S/Release

На данный момент уже (или еще...) не понимаю разницы между ними, что лучше использовать?

Вот что говорит man apt-get

upgrade
upgrade используется для установки новейших версий всех установленных пакетов системы из источников, указанных в /etc/apt/sources.list. Будут разысканы новейшие версии установленных в настоящий момент пакетов и произведено обновление; ни в коем случае не будет удалено ни одного установленного пакета или установлено нового пакета, не имеющего уже установленной в системе предыдущей версии. Текущие версии установленных в настоящий момент пакетов, если они не могут быть обновлены новыми версиями без изменения статуса других пакетов, будут оставлены в неизменном виде. Для того, чтобы apt-get узнал о существовании доступных новых версиях пакетов, данной команде должна предшествовать команда update.

dist-upgrade
dist-upgrade, в дополнение выполняет функцию upgrade, а также разумно управляет изменением зависимостей с новыми версиями пакетов; apt-get имеет "умную" систему разрешения конфликтов и она будет в случае необходимости пытаться произвести обновление наиболее важных пакетов за счет менее важных. Файл /etc/apt/sources.list содержит список источников для получения пакетов, из которых будут получены файлы пакетов.

Лучше, чем здесь, я всё равно не изложил бы.

Лучше? Да ладно, если перевод upgrade хотя бы полный, но, по моему мнению, слишком длинный и за всеми этими словами очень легко не увидеть главного:

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

, то вот перевод dist-upgrade вообще не содержит самой главной фразы:

The dist-upgrade command may therefore remove some packages.

В этом вся разница.

[QWERTYASDF]

Т.е.localhost открытым ключом переводит gpg-подписи в md5 etc хеши соответствующих файлов, что возможно только в случае создания первых из последних с помощью закрытого ключа?

Поставила тот пакет с ключами, и выдается только такая ошибка:

Код: Выделить всё

W: Ошибка GPG: ftp://ftp.ru.debian.org stable Release: Неизвестная ошибка при выполнении gpgv

Как понимаю, лучше сначала сделать

Код: Выделить всё

apt-get upgrade

и уже в случае наличия ошибок можно прибегнуть к

Код: Выделить всё

apt-get dist-upgrade

?

[Hephaestus]

Т.е.localhost открытым ключом переводит gpg-подписи в md5 etc хеши соответствующих файлов, что возможно только в случае создания первых из последних с помощью закрытого ключа?

Зачем? Просто проверяет цифровую подпись.
Можете попробовать сами.
Есть такой инструмент gpg.

Создаёте пару ключей.
Берете любой файл (например, текстовый, для наглядности).
Делаете копию.
Эту копию подписываете своим закрытым ключом.
Проверяете подпись своим открытым ключом.
Сравниваете содержимое подписанной копии с неподписанным оригиналом.
Различия увидите сами.

Как понимаю, лучше сначала сделать

Код: Выделить всё

apt-get upgrade

и уже в случае наличия ошибок можно прибегнуть к

Код: Выделить всё

apt-get dist-upgrade

?

Ну как-то так, да.

Поставила тот пакет с ключами, и выдается только такая ошибка:

Подобные ситуации обнаруживаются в гугле, но я воздержусь от советов по этому поводу, дабы не ввести в заблуждение. В работу apt-get я глубоко не вникал. Быть может, более сведущие коллеги подскажут что-то конкретное.

[sgfault]

Т.е.localhost открытым ключом переводит gpg-подписи в md5 etc хеши соответствующих файлов, что возможно только в случае создания первых из последних с помощью закрытого ключа?

ээ.. не совсем, если я правильно вас понял. На картинке нарисовано, как в дебиановском репозитории проверяется, что пакет не был изменен.
Возьмем, например, репозиторий Jessie и архитектуру i386. Корневая папка репозитория dists/jessie. Цепочка начинается с вычисления хеша пакета и записывания его (хеша) в файл D/C/B/Packages, те в данном случае это будет dists/jessie/main/binary-i386/Packages.gz :

Код: Выделить всё

$ sed -ne'1,/^$/p' Packages
Package: 0ad
Version: 0.0.16-3
Installed-Size: 9495
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Architecture: i386
Depends: 0ad-data (>= 0.0.16), 0ad-data (<= 0.0.16-3), 0ad-data-common (>= 0.0.16), 0ad-data-common (<= 0.0.16-3), libboost-filesystem1.55.0, libc6 (>= 2.15), libcurl3-gnutls (>= 7.16.2), libenet7, libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libgloox12, libicu52 (>= 52~m1-1~), libjpeg8 (>= 8c), libminiupnpc8 (>= 1.6), libmozjs-24-0, libnvtt2, libopenal1, libpng12-0 (>= 1.2.13-4), libsdl1.2debian (>= 1.2.11), libstdc++6 (>= 4.9), libvorbisfile3 (>= 1.1.2), libwxbase3.0-0 (>= 3.0.0), libwxgtk3.0-0 (>= 3.0.0), libx11-6, libxcursor1 (>> 1.1.2), libxml2 (>= 2.9.0), zlib1g (>= 1:1.2.0)
Pre-Depends: dpkg (>= 1.15.6~)
Description: Real-time strategy game of ancient warfare
Homepage: http://play0ad.com/
Description-md5: d943033bedada21853d2ae54a2578a7b
Tag: uitoolkit::sdl, uitoolkit::wxwidgets
Section: games
Priority: optional
Filename: pool/main/0/0ad/0ad_0.0.16-3_i386.deb
Size: 2714156
MD5sum: b7760ad3391e273d173540e0b5020b9d
SHA1: dd45adb6fbb742c857c549161cdb6c51fde453f7
SHA256: d37b8381c8a4d4a030016847c5956dda47e06d649476eafa595122a8

в конце записаны хеши. То же самое делается с исходниками: считаются хеши файлов .dsc, .tar.gz, .diff.gz (может еще каких-то):

Код: Выделить всё

$ zcat Sources.gz | sed -ne'1,/^$/p'
Package: 0ad
Binary: 0ad, 0ad-dbg
Version: 0.0.16-3
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Uploaders: Vincent Cheng <vcheng@debian.org>
Build-Depends: autoconf, debhelper (>= 9), dpkg-dev (>= 1.15.5), libboost-dev, libboost-filesystem-dev, libboost-signals-dev, libcurl4-gnutls-dev | libcurl4-dev, libenet-dev (>= 1.3), libgloox-dev (>= 1.0.9), libicu-dev, libjpeg-dev, libminiupnpc-dev (>= 1.6), libmozjs-24-dev, libnvtt-dev (>= 2.0.8-1+dfsg-4~), libogg-dev, libopenal-dev, libpng-dev, libsdl1.2-dev, libvorbis-dev, libwxgtk3.0-dev | libwxgtk2.8-dev, libxcursor-dev, libxml2-dev, pkg-config, zlib1g-dev
Architecture: amd64 armhf i386 kfreebsd-amd64 kfreebsd-i386
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 b3a3c7eafffaa584e7b258b357c8fac0 2465 0ad_0.0.16-3.dsc
 3836bbcdf4edc57c2354b4fef6023146 20019680 0ad_0.0.16.orig.tar.xz
 028b8b46b038a78fd5c2077fb54b30a7 93688 0ad_0.0.16-3.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/0ad/
Vcs-Svn: svn://anonscm.debian.org/pkg-games/packages/trunk/0ad/
Checksums-Sha1:
 e3b2f4b5cb8386d9aafe2524609cc06118b8239d 2465 0ad_0.0.16-3.dsc
 4931b9f6cd68ef131832eeedf8b502b54f204cce 20019680 0ad_0.0.16.orig.tar.xz
 94820d5c2a8fcc01edb19a31933d0401ea51bf8e 93688 0ad_0.0.16-3.debian.tar.xz
Checksums-Sha256:
 1e10c248c2ba6354ba6dc772919414958baa34f1bfe3bc056bb2f1d03f4617ec 2465 0ad_0.0.16-3.dsc
 cb965ef7e292bc3a2f1f598a9695e16ff4d786398f384a1ec7d5f9bfe2626de5 20019680 0ad_0.0.16.orig.tar.xz
 20b1b46d52631c6ba65017bd42a7dc9048226248fe1f5c8f4ba9df5e3895313e 93688 0ad_0.0.16-3.debian.tar.xz
Homepage: http://play0ad.com/
Package-List:
 0ad deb games optional arch=amd64,armhf,i386,kfreebsd-amd64,kfreebsd-i386
 0ad-dbg deb debug extra arch=amd64,armhf,i386,kfreebsd-amd64,kfreebsd-i386
Directory: pool/main/0/0ad
Priority: source
Section: games

Затем, чтобы быть уверенным, что Packages (для всех архитектур) и Sources не были изменены, хеши этих файлов записываются в dists/jessie/Release. И затем, чтобы быть уверенным, что Release не был изменен, он подписывается закрытым ключом Дебиана (те, тоже считается хеш и зашифровывается закрытым ключом) и подпись сохраняется в файле Release.gpg. Тогда, чтобы проверить, что ни один из хешей не был изменен, apt проверяет подпись файла Release (расшифровывает Release.gpg и смотрит совпадет ли расшифрованный хеш с посчитанным хешем файла Release), затем проверяет хеши файлов Packages и, в конце, самих .deb пакетов.

Поставила тот пакет с ключами, и выдается только такая ошибка:

Код: Выделить всё

W: Ошибка GPG: ftp://ftp.ru.debian.org stable Release: Неизвестная ошибка при выполнении gpgv

Вы поставили debian-keyring или debian-archive-keyring ? Если только первый, то обновите второй пакет (сделав apt-get update перед этим).
Также, проверьте, что у вас установлено правильное время.
И покажите

Код: Выделить всё

# apt-key list

Как понимаю, лучше сначала сделать

Код: Выделить всё

apt-get upgrade

и уже в случае наличия ошибок можно прибегнуть к

Код: Выделить всё

apt-get dist-upgrade

?

Если вы собираетесь потом делать dist-upgrade, нет смысла сначала делать upgrade. И если у вас нет причин *не* делать dist-upgrade, то выполняйте именно его (dist-upgrade).

[Hephaestus]

Вы поставили debian-keyring или debian-archive-keyring ? Если только первый, то обновите второй пакет (сделав apt-get update перед этим).

Не сработает. Там же apt-get update завершается с ошибкой из-за ключей,

Если вы собираетесь потом делать dist-upgrade, нет смысла сначала делать upgrade. И если у вас нет причин *не* делать dist-upgrade, то выполняйте именно его (dist-upgrade).

По крайней мере раньше в руководстве по установке Debian в главе об обновлениях рекомендовали сначала делать apt-get upgrade как более безопасный (не приведет к краху системы), а затем уже apt-get dist-upgrade.

[QWERTYASDF]

в дебиановском репозитории проверяется, что пакет не был изменен.

Ну, насколько поняла, первичная цель - проверить, не с ложным ли репозиторием мы имеем дело (что это действительно rep.ru , а не rep.ua, прикинувшийся первым).

apt проверяет подпись файла Release (расшифровывает Release.gpg и смотрит совпадет ли расшифрованный хеш с посчитанным хешем файла Release)

Так вот я это и имела ввиду - не будь подпись md5-хеша файла Release произведена с помощью закрытого ключа, имеющегося только у истинного репозитория, то с помощью соответствующего открытого ключа apt не преобразовал-бы эту подпись обратно в хеш Release. Дело тут прежде всего в том, чтобы подтвердить наличие у той стороны закрытого ключа, а для этого в принципе и не обязательно сравнивать хеши файлов, составляющих структуру репозитория, можно выложить вообще md5 и md5-->gpg хеши произвольного файла, а другая сторона открытым ключом преобразует второе в первое и посчитает аутентификацию успешной. Разумеется, на самом деле реальная система не посчитает т.к. она так не настроена и помимо Release проверяются еще и остальные файлы, указанные в привиденной выше схеме. Однако, для меня интересен сам механизм аутентификации.

Решила сейчас еще раз сделать

Код: Выделить всё

apt-get update

и больше никаких ошибок в конце не выдается : )

[Bizdelnick]

Т.е.localhost открытым ключом переводит gpg-подписи в md5 etc хеши соответствующих файлов, что возможно только в случае создания первых из последних с помощью закрытого ключа?

Зачем? Просто проверяет цифровую подпись.

Всё правильно, цифровая подпись в общих чертах именно так и работает. Только там не MD5 скорее всего, а более современный алгоритм (лень проверять).

[Bizdelnick]

cat /etc/apt/sources.list

Зря Вы намешали wheezy и stable. Используйте что-нибудь одно. Иначе, когда wheezy перестанет быть stable, начнутся проблемы.
И с testing-репозиториями надо быть аккуратнее. Вы, надеюсь, приоритет понизить для них не забыли?

[QWERTYASDF]

cat /etc/apt/sources.list

Зря Вы намешали wheezy и stable. Используйте что-нибудь одно. Иначе, когда wheezy перестанет быть stable, начнутся проблемы.
И с testing-репозиториями надо быть аккуратнее. Вы, надеюсь, приоритет понизить для них не забыли?

Заменила всюду stable на wheezy.

В

Код: Выделить всё

deb http://www.deb-multimedia.org testing main non-free

заменила testing на wheezy. Насчет приоритетов я не очень понимаю, на дебианской-вики для меня мало понятной информации, а в остальных местах примеры часто разные и тем самым еще более непонятные. Если Вы мне дадите ссылочку, где почитать на русском про логику приоритетов - была б очень признательна. А вообще, я где-то читала, да и кажется логичным - по умолчанию же apt отдает приоритет stablе, так зачем еще дополнительно что-то придумывать с понижением приоритетов для тестируемых/нестабильных репозиториев?

[sgfault]

в дебиановском репозитории проверяется, что пакет не был изменен.

Ну, насколько поняла, первичная цель - проверить, не с ложным ли репозиторием мы имеем дело (что это действительно rep.ru , а не rep.ua, прикинувшийся первым).

Нет, первичная цель проверить, что пакет не был изменен. Данная цепочка нигде не содержит адреса репозитория, поэтому, например, вы можете скачать весь репозиторий дебиана (вместе с подписью) и обновляться с него (прописав при этом в sources.list новый адрес). apt не заметит разницы до тех пор, пока вы не решите изменить какой-то из пакетов. Debian Wiki - SecureApt/Secure apt groundwork: checksums:

<..>
These two checksums allow apt to verify that it has downloaded a correct copy of the Packages file, with a checksum that matches the one in the Release file. And when it downloads an individual package, it can also check its checksum <..>
Notice that so far there is one file that apt doesn't have a way to check: The Release file. Secure apt is all about making apt verify the Release file<..>

Дело тут прежде всего в том, чтобы подтвердить наличие у той стороны закрытого ключа, а для этого в принципе и не обязательно сравнивать хеши файлов, составляющих структуру репозитория, можно выложить вообще md5 и md5-->gpg хеши произвольного файла, а другая сторона открытым ключом преобразует второе в первое и посчитает аутентификацию успешной. Разумеется, на самом деле реальная система не посчитает т.к. она так не настроена и помимо Release проверяются еще и остальные файлы, указанные в привиденной выше схеме. Однако, для меня интересен сам механизм аутентификации.

Нет никакой аутентификации. Есть только проверка целостности скачанного пакета. И эта операция выполняется для конкретного пакета, с которым apt работает в данный момент, а не для всех файлов репозитория (последнее просто не имеет смысла).

[sgfault]

А вообще, я где-то читала, да и кажется логичным - по умолчанию же apt отдает приоритет stablе, так зачем еще дополнительно что-то придумывать с понижением приоритетов для тестируемых/нестабильных репозиториев?

Нет, если приоритеты не были переопределены тем или иным способом, то по умолчанию приоритет 500 для всего, перечисленного в sources.list . И это значит, что ничего не мешает apt обновить пакеты до максимальной версии (например, из unstable). Лишь некоторые репозитории, вроде backports, содержат в Release файлах строчки вроде

Код: Выделить всё

NotAutomatic: yes

понижающие приоритет всех пакетов репозитория до (кажется) 100. Переопределен приоритет может быть либо в apt/preferences (apt/perefences.d), или через переменную APT::Default-Release в apt.conf, в которой может указываться как codenemae (squeeze, wheezy), так и suite (stable, testing).

[Bizdelnick]

Если Вы мне дадите ссылочку, где почитать на русском про логику приоритетов - была б очень признательна.

Лучше, чем на вики и в man apt_preferences, нигде не видел описания. Для себя когда-то давно сделал так:

Spoiler

Код: Выделить всё

Package: *
Pin: origin "security.debian.org"
Pin-Priority: 990

Package: *
Pin: release n=wheezy
Pin-Priority: 800

Package: *
Pin: release n=wheezy-proposed-updates
Pin-Priority: 900

Package: *
Pin: release n=wheezy/updates
Pin-Priority: 900

Package: *
Pin: release n=wheezy-backports
Pin-Priority: 700

Package: *
Pin: release n=jessie
Pin-Priority: 400

Package: *
Pin: release n=jessie-proposed-updates
Pin-Priority: 400

Package: *
Pin: release n=jessie/updates
Pin-Priority: 400

Package: *
Pin: release n=sid
Pin-Priority: 200

Package: *
Pin: release a=experimental
Pin-Priority: 100

А вообще, я где-то читала, да и кажется логичным - по умолчанию же apt отдает приоритет stablе, так зачем еще дополнительно что-то придумывать с понижением приоритетов для тестируемых/нестабильных репозиториев?

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

[QWERTYASDF]

А номер версии пакета однозначно его идентифицирует? К сожалению сейчас не смогла найти источник, но кажется недавно читала, что модифицированные пакеты более нового релиза могут иметь такой-же номер версии, как и у старых. А различие (в файле control, вроде) указывается в неких прочих атрибутах. Т.е. для apt-get install два пакета из репозиториев разных редакций могут показаться одинаковым (не учитывая очевидной разности файлового хеша) из-за указанной одинаковой версии, а на самом деле один будет уже частично модифицирован. Или я чего-то конкретно уже путаю? ))) Уж простите...

[Bizdelnick]

Пакет однозначно идентифицируется номерами версии и релиза. Если какое-то изменение вносилось без поднятия номера версии, то поднимается номер релиза. Путаницы возникнуть не может.

[QWERTYASDF]

Пакет однозначно идентифицируется номерами версии и релиза. Если какое-то изменение вносилось без поднятия номера версии, то поднимается номер релиза. Путаницы возникнуть не может.

Оные находятся в файле Packages репозитория? В .deb-файле, насколько поняла, может находится только номер версии пакета и оный имеет весьма условное значение т.к. не стандартизирован.

[Bizdelnick]

В .deb-файле, насколько поняла, может находится только номер версии пакета и оный имеет весьма условное значение т.к. не стандартизирован.

Вот этот номер состоит из номера версии программы (который из апстрима) и добавленного к нему номера релиза. Иногда в начале ещё стоит номер эпохи (если его нет - он считается равным 0). Значение номера имеют вполне однозначное, стандартизованы в политике Debian.

Upd. Сорри, в терминологии Debian это называется не релизом, а ревизией. Раздел 5.6.12 политики.

[QWERTYASDF]

Читала, что проект Debian поддерживает oldstable-дистрибутивы путем выпуска обновлений безопасности пакетов для данных дистрибутивов. В плане именования/нумерации oldstable пакетов это выражается ввиде изменения номера программы? Номер релиза при этом остается прежним?

[Bizdelnick]

Наоборот.
И при изменении номера версии релиз/ревизия прежней не остаётся почти никогда. Она имеет смысл только для конкретной версии, при выходе новой версии нумерация начинается заново.

[QWERTYASDF]

Т.е. формат нумерации oldstable пакетов не отличается от формата нумерации для stable и новее?

[Bizdelnick]

Нет, нумерация сквозная для всех веток.

[QWERTYASDF]

А как тогда нумеруются oldstable пакеты? Ну, есть например некий пакет с версией программы 4, ревизии 5 и дистрибутив переходит в oldstable. На stable появляется обновление пакета 5,6. В рамках сопровождения этого пакета для oldstable, как будет меняться его нумерация?