Я прочитал следующую статью: Как я могу обойти / игнорировать проверки подписи gpg apt?
Он описывает , как настроить , aptчтобы не проверять подписи пакетов на всех .
Однако я бы хотел ограничить действие этого параметра одним (в данном случае локально размещенным) репозиторием.
То есть: все официальные репозитории должны использовать проверку подписи GPG , как обычно, за исключением того, для местных репо .
Как бы я поступил так?
В противном случае, каково было бы преимущество (с точки зрения безопасности) подписания пакетов во время автоматической сборки (некоторые метапакеты и несколько программ), а затем выполнение всего, что предписано безопаснымapt способом? Ведь хост с репо тоже будет тем, на котором находится секретный ключ GPG.
По моему мнению, автоматическая подпись с использованием онлайн-ключа, хотя и далека от идеала, была бы строго лучше, чем вообще не подписывать. Также было бы намного проще установить (не нужно настраивать каждый клиент, чтобы отказаться от проверок), и намного легче перейти к лучшей настройке позже, если вы захотите.
—
Селада
@Celada: это мнение (что оно «строго лучше») или есть ли обоснование для вашего заявления? Я спрашиваю, потому что до сих пор я не вижу причины, как это улучшит безопасность или любой другой аспект. Единственный случай, когда это было бы несколько выгодно, было бы, если бы я все-таки намеревался опубликовать мой репо, не так ли?
—
0xC0000022L
Я придерживаюсь этого мнения рационально :-) Если репозиторий подписан, то, по крайней мере, плохие парни должны получить ключ подписи, который вы, вероятно, будете хранить только в одном месте и, вероятно, в окне разработчика, или, по крайней мере, не читаемый HTTP-сервер. В противном случае нет никакой защиты вообще. Другими словами, я просто хочу сказать, что нет недостатка в подписи, так что вы могли бы также подписать, даже если преимущество только крошечное. И так как это было бы легче настроить, это то, с чем я бы пошел.
—
Селада
@Celada: это хранилище только для локального использования. Кто сможет получить к нему доступ. Вариант использования: хост с гостевыми контейнерами. И хост, и контейнеры будут иметь доступ. Публичный доступ не планируется. Но, думаю, я подожду немного дольше и пойду к неизбежному (подписание).
—
0xC0000022L
Справедливо, посмотрим, знает ли кто-нибудь ответ на ваш вопрос. Я не знаю, какой инструмент вы планируете использовать для генерации репо, но я рекомендую перезагрузку . Многие другие инструменты, такие как
—
Селада
dput(или то, что использует сам Debian), очень сложны и кажутся огромным излишним для локального оперативного репо. repreproпозаботится о создании хранилища со всеми правильными макетами каталогов и индексными файлами автоматически, без необходимости установки большого сервера базы данных ... и также подпишет результат, практически без дополнительной работы с вашей стороны.