Strona man Ubuntu apt-key obejmuje następujące notatkę dotyczącą apt-key add:

Uwaga: Zamiast używać tego polecenia, klucz należy umieścić bezpośrednio w katalogu /etc/apt/trusted.gpg.d/ z nazwą opisową i „gpg” lub „asc” jako rozszerzeniem pliku.

Nie sądzę, żebym kiedykolwiek widział tę radę gdzie indziej. Większość projektów, które przechowują własne repozytoria, mówi o pobraniu pliku klucza i dodaniu go apt-key.

1. Jaka jest motywacja tej porady?
2. Czy jest to Ubuntu-ism, czy może dotyczy dowolnej dystrybucji opartej na APT?

Te projekty mają nieaktualne instrukcje. Wiem o tym, ponieważ publikuję repozytorium Debiana i zaktualizowałem instrukcje, gdy dowiedziałem się o zmianach w APT Debiana 9. Rzeczywiście, ta część instrukcji jest już nieaktualna, ponieważ jest to zły katalog.

To nie jest tak naprawdę związane z .dkatalogami, a więcej z zapobieganiem podatności na atak krzyżowy w APT. Starszy system dla wygody używał osobnych plików kluczy, ale jest to obecnie konieczność bezpieczeństwa; twoje bezpieczeństwo.

To jest luka w zabezpieczeniach. Rozważmy dwóch wydawców repozytoriów, A i B. W świecie Debiana 8 i wcześniejszych klucze obu wydawców znajdowały się w jednym globalnym kluczu na komputerach użytkowników. Jeśli wydawca A mógłby w jakiś sposób zorganizować zastąpienie strony WWW repozytorium wydawcy B, wówczas A mógłby opublikować wywrotowe pakiety, podpisane własnym kluczem A , które APT chętnie zaakceptowałby i zainstalował. Klucz A jest przecież zaufany globalnie dla wszystkich repozytoriów.

Ograniczeniem jest użycie przez użytkowników osobnych kluczy dla poszczególnych wydawców i odniesienie tych kluczy do indywidualnych Signed-Byustawień w definicjach repozytoriów. W szczególności klucz wydawcy A jest używany tylko w Signed-Byrepozytorium A, a klucz wydawcy B jest używany tylko w Signed-Byrepozytorium B. W ten sposób, jeśli wydawca A zastąpi repozytorium wydawcy B, APT nie zaakceptuje pakietów wywrotowych z niego, ponieważ oni i repozytorium jest podpisane przez klucz wydawcy A, a nie przez wydawcę B.

/etc/apt/trusted.gpg.dMechanizm pod ręką jest starszy nieco wadliwy dom połowie biedaka w tym kierunku, z powrotem w 2005 roku lub tak, że nie jest dość dobry wystarczy. Ustawia brelok w osobnym pliku, dzięki czemu można go spakować i po prostu zainstalować w jednym kroku przez menedżera pakietów (lub pobrać za pomocą fetch/ curl/ wget) jak każdy inny plik. (Menedżer pakietów obsługuje zapobieganie instalowaniu specjalnego pakietu wydawcy A to-moje-repozytorium-klucze nad wydawcą B, w normalny sposób, który obsługuje konflikty plików między pakietami w ogóle). Ale nadal dodaje go do zestawu kluczy który jest globalnie zaufany dla wszystkich repozytoriów. Pełny mechanizm, który istnieje obecnie wykorzystuje oddzielne, nie ufał globalnie, brelok plików /usr/share/keyrings/.

Moje instrukcje już tam są. Af Trwają kroki w celu przeniesienia własnych repozytoriów Debiana do tego mechanizmu, tak że nie będą już używać globalnie zaufanych kluczy. Możesz chcieć pogadać z tymi „większością projektów”, które znalazłeś. W końcu instruują cię, abyś przekazał im globalny dostęp do APT na twoim komputerze.

Dalsza lektura

• Daniel Kahn Gillmor (02.05.2017). Klucze do wydania należy wysyłać osobno poza/etc/apt/trusted.gpg.d/ . Błąd Debiana # 861695.
• Daniel Kahn Gillmor (2017-07-27). wpisy debiana sources.listpowinny mieć podpisane opcje wskazujące na określone klucze . Błąd Debiana # 877012.
• „Wpis Sources.list” . Instrukcje dotyczące łączenia się z repozytorium innej firmy . Debian Wiki. 2018 r.
• Dlaczego dodanie do pliku sources.list nie stanowi zagrożenia dla bezpieczeństwa?
• Debian 9, APT i „Błąd GPG: ... InRelease: Następujące podpisy były nieprawidłowe:”

apt-key delbierze keyid, co jest bezsensownym skrótem klucza.

Łatwiej jest odinstalować klucze, używając sensownej nazwy ... jak nazwa pliku.

Jak mówi JdeBP, działa to dobrze z zaufanymi plikami kluczy, które są instalowane jako część pakietu debian. Myślę, że może być też ładniej, gdy ręcznie zainstalujesz plik klucza.

W nowym mechanizmie, który jest obecnie w fazie „wstępnych testów”, jest to jeszcze bardziej uproszczone. Musisz tylko usunąć / wyłączyć jedną rzecz: repozytorium (w sources.list / sources.list.d). To automatycznie przestanie zezwalać na klucz skonfigurowany dla tego repozytorium (chyba że był również używany przez inne repozytorium).

Nie wiem, jak skorzystać z nowego mechanizmu bezpieczeństwa. Po prostu zakładam, że muszę komuś zaufać, jeśli skorzystam z jego pakietu. Proces instalacji pakietu nadal działa jako root:-).