Абнаўленне apt падае з NO_PUBKEY пасля дадання рэпазіторыя VPN

Крыніца apt вашага пастаўшчыка VPN зламала ваш мэнэджар пакетаў, і выпраўленне — гэта рашэнне, а не каманда. NO_PUBKEY, ці скарга на тое, што ў рэпазіторыі няма файла Release, азначае, што apt адмовіўся давяраць гэтай крыніцы, таму кожная наступная аперацыя з пакетамі працягвае друкаваць тое ж папярэджанне. Сам тунель, хутчэй за ўсё, невінаваты. Адкажыце на тры пытанні пра тое, ці ўсё яшчэ патрэбна гэтая крыніца, і правільнае выпраўленне прыйдзе амаль механічна.

Спачатку аднясіце збой да правільнай катэгорыі

Збой даверу называе файл крыніцы і альбо адсутны ключ, альбо няма файла Release. Збой перадачы выглядае інакш: памылкі сертыфіката TLS, адмова ў злучэнні, тайм-аўты або проксі, які адмаўляе CONNECT. Гэтае адрозненне вызначае, які артыкул вы чытаеце, бо VPN, які перахоплівае TLS або блакуе хост пастаўшчыка, дае памылкі перадачы, а не памылкі подпісу.

Запусціце sudo apt update асобна і прачытайце хвост, ігнаруючы закешаваныя трапленні вышэй. Радок, які мае значэнне, называе /etc/apt/sources.list.d/ і кажа вам, які файл адкрыць.

Калі збой ідзе за ўзняццем тунеля, праверце з выключаным тунелем і з DNS, які вырашаецца сістэмным рэзалверам. Крыніца, якая працуе без VPN, — гэта пытанне маршрутызацыі або перахопу, і ніякая колькасць кіравання ключамі гэта не выправіць.

Тры пытанні, якія выбіраюць шлях

Ці ўсё яшчэ ўсталёўваеце або абнаўляеце пакеты з гэтай крыніцы? Калі кліент актыўна выкарыстоўваецца, адрамантуйце давер. Калі вы ўсталявалі кліент адзін раз і цяпер імпартуеце звычайны профіль у NetworkManager, крыніца — баласт, і выдаленне — сумленнае выпраўленне.

Па-другое, ці публікуе пастаўшчык ключ і адбітак, якія вы можаце праверыць па-за каналам? Па-трэцяе, хто кіруе ключамі на гэтым хосце: дыстрыбутыў ці вы? Крыніца, падпісаная ключом, які вы не можаце праверыць, — гэта паўнамоцтва абнаўлення, якое вы не павінны даваць.

Адказ не на першае пытанне завяршае аналіз. Адказ так на ўсе тры пункты паказвае на выпраўленне праз signed-by, і гэта адзіная схема, якая адначасова працуе і застаецца праверанай. Змешванне двух шляхоў, калі крыніца застаецца і яе прымусова прапіхваюць, — адзіны варыянт, які варта відавочна выключыць.

Чаму trusted=yes выглядае як выпраўленне і не з'яўляецца ім

Старонка кіраўніцтва sources.list кажа пра гэта прама. Усталяванне опцыі Trusted у yes кажа apt прымаць крыніцу нават тады, калі яна не праходзіць аўтэнтыфікацыю, што выключае apt-secure для гэтага рэпазіторыя. Старонка пакідае гэта для лакальнага кантэксту, калі гэта ўвогуле выкарыстоўваецца.

Гэта не вузейшая версія даверу да пастаўшчыка. Гэта прыбірае пытанне пра тое, хто падпісаў індэкс, таму любы, хто можа адказаць за гэтае імя хоста, можа даць вашай машыне пакеты, якія ўсталююцца з правамі root.

Шлях рамонту: атрымайце ключ, затым замацуйце яго

Атрымайце ключ з месца, якое дакументуе пастаўшчык, і распакуйце яго ў ключніцу, якой кіруе адміністратар, затым накіруйце радок рэпазіторыя на гэты файл, каб давер не мог з'ехаць.

1. Прачытайце радок, які падае, каб атрымаць ID ключа і імя файла крыніцы.
2. Спампуйце ключ пастаўшчыка ў ASCII-брані і выканайце gpg --dearmor у /etc/apt/keyrings/vendor-name.gpg.
3. Дадайце [signed-by=/etc/apt/keyrings/vendor-name.gpg] да запісу ў файле .list гэтага пастаўшчыка.
4. Запусціце sudo apt update і пераканайцеся, што крыніца атрымлівае індэкс, а не паўтарае папярэджанне пра подпіс.

Аддавайце перавагу /usr/share/keyrings для ключоў, якія прыходзяць з пакетам, і /etc/apt/keyrings для ключоў, якія вы кладзяце ўручную. Гэтае размеркаванне не касметычнае: яно кажа наступнаму адміністратару, якія ключы перажывуць абнаўленне пакета, а якія патрабуюць чалавека.

Праверце адбітак супраць апублікаванага значэння пастаўшчыка, перш чым давяраць яму. ID ключа, устаўлены з допісу на форуме, — гэта тое, як машына пачынае давяраць паўнамоцтву абнаўлення, якога ніхто не можа назваць.

Шлях выдалення і чаму памылка можа вярнуцца

Паглядзіце, што ўсталёўшчык сапраўды запісаў, бо некалькі файлаў могуць згадваць аднаго пастаўшчыка, і адзін з іх звычайна рэшткавая копія.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt чытае толькі файлы .list і .sources з гэтага каталога, таму копія .save або .distUpgrade ужо ігнаруецца; выдаленне яе ўсё роўна не дазваляе пазнейшаму чытачу выпадкова яе аднавіць. Выдаленне крыніцы нічога не дэінсталюе, і apt можа тады апісаць усталяваны пакет VPN як усталяваны лакальна або больш недаступны, што з'яўляецца паведамленнем пра стан пакета, а не вяртаннем памылкі даверу.

Паўторны выпадак — гэта старыя інструкцыі, якія ўсталёўвалі ключы праз apt-key у глабальнае даверанае кольца. Гэты шлях састарэлы, і абнаўленне выпуску можа пакінуць ключ скінутым або проста не ўжытым, і менавіта таму памылка, якая маўчала год, з'яўляецца на тыдні вашага абнаўлення. Праверце /etc/apt/trusted.gpg.d/, затым перанясіце рашэнне пра давер у радок рэпазіторыя, дзе яно і павінна быць. Калі пастаўшчык усё яшчэ друкуе інструкцыі apt-key, усё роўна выкарыстоўвайце signed-by; гэта схема, якую дакументуе кіраўніцтва, і яна ж перажывае абнаўленне.