Eksport Reprepro nie mógł znaleźć klucza do podpisywania

Mamy prywatne repozytorium debiana, które zostało utworzone lata temu przez wcześniejszego administratora systemu. Pakiety zostały podpisane przez starszy klucz, 7610DDDE (który musiałem odwołać), jak pokazano tutaj dla użytkownika root na serwerze repo.

# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid                  Debian Archive Automatic Signing Key (2006)  <[email protected]>

pub   1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid                  Archive Maintainer <[email protected]>

pub   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

Wszystkie poniższe polecenia są jako użytkownik root. Zmodyfikowałem plik repozytorium / conf / dystrybucji, aby użyć nowego podklucza, który utworzyłem jawnie do podpisywania:

Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672

Ale kiedy używam dput do aktualizacji pakietu, otrzymuję

Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)

A kiedy uruchamiam bezpośrednio reprezentację eksportu, otrzymuję:

# reprepro -V export unstable
Exporting unstable...
 generating main/Contents-i386...
 generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!

Poszukałem google i znalazłem kilka starych wątków, które wskazywały na możliwy problem z reprezentowaniem właściwego katalogu gnupg ... więc spróbowałem tego z tymi samymi wynikami powyżej:

# GNUPGHOME=/root/.gnupg reprepro -V export unstable

Jeden wątek sugerował przetestowanie klucza przez podpisanie fałszywego pliku, który wydawał się działać dobrze ... przynajmniej nie zgłaszał żadnych błędów i skończyłem z 576 bajtowym plikiem bla.gpg po jego zakończeniu.

# touch bla
# gpg -u DD219672 --sign bla

Reprezentatywna strona podręcznika sugeruje również: "Jeśli występują problemy z podpisywaniem, możesz wypróbować wartość gpg --list-secret-keys, aby zobaczyć, w jaki sposób gpg może interpretować wartość. Jeśli to polecenie nie wyświetla żadnych kluczy ani wielu, spróbuj znaleźć jakąś inną wartość (jak keyid), którą gpg może łatwiej powiązać z unikalnym kluczem. ” Sprawdziłem to również i otrzymałem:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <[email protected]>

I w końcu udało mi się skontaktować z administratorem sys, który jako pierwszy skonfigurował nasze poprawki, i zasugerował wypróbowanie klucza bez hasła. Wygenerowałem więc nowy klucz do podpisu, DD219672, opublikowałem go, ponownie wykonałem powyższe kroki, ale z takim samym rezultatem.

Dzisiaj, po dokładniejszym przeczytaniu i przestudiowaniu stron podręcznika użytkownika i zauważeniu, że pgp-agent jest automatycznie uruchamiany, kiedy uruchamiam reprezentpro, zdecydowałem się go przez chwilę ścigać.

Dodałem gpg-agent.conf z

debug-level 7
log-file    /root/gpg.agent.log
debug-all

I widzę w dzienniku, że gpg-agent nie znajduje kluczy

2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]

Do tej pory nie byłem w stanie dowiedzieć się, gdzie gpg-agent znajduje klucze wymienione w HAVKEY i jak skierować go we właściwym kierunku, aby znaleźć nowy klucz, DD219672, do podpisania naszych zaktualizowanych pakietów.

Miałem ten sam problem i po wielu frustracjach wreszcie wyśledziłem, co się dzieje.

repreproGpgme zastosowania narzędzi, które opiera się na gnupg2. Ostatnie wydanie tego zmieniło sposób obsługi tajnego breloka: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg używane do przechowywania par kluczy publicznych w dwóch plikach: pubring.gpgi secring.gpg... W GnuPG 2.1 to się zmieniło ... Aby ułatwić migrację do metody bez zabezpieczenia, gpg wykrywa obecność a secring.gpgi konwertuje klucze w locie do magazynu kluczy gpg-agent (jest to private-keys-v1.dkatalog poniżej katalogu domowego GnuPG ( ~/.gnupg)). Odbywa się to tylko raz, a secring.gpggpg już nie dotyka istniejącego . Pozwala to na współistnienie starszych wersji GnuPG z GnuPG 2.1. Jednak wszelkie zmiany w kluczach prywatnych przy użyciu nowego gpg nie pojawią się w przypadku używania GnuPG w wersjach wcześniejszych niż 2.1 i odwrotnie.

Tak więc, jeśli utworzysz nowy klucz za pomocą gpg, gpg2 go nie zobaczy i na odwrót.

Szybka poprawka, która zadziałała dla mnie:

gpg --export-secret-keys | gpg2 --import -

A jeśli musisz iść w drugą stronę, oczywiście:

gpg2 --export-secret-keys | gpg --import -

W zależności od konfiguracji możesz także chcieć / trzeba dodać --export-secret-subkeys

Po wykonaniu powyższych czynności repreprodziałał poprawnie z moim nowym kluczem.

Dla mnie problemem było to, że wygenerowałem klucze jako użytkownik i uruchomiłem reprezentpro jako root .

Stało się tak, że klucze, które generuję „bez sudo”, są dodawane do mojego lokalnego pubring.gpg. Kiedy uruchamiam sudo reprepro ..., uruchamiam go jako root i dlatego próbuje znaleźć klucz w rootie pubring.gpgi oczywiście go nie znajduje.

Rozwiązaniem było uruchomienie wszystkich gpgpoleceń jako root (równ. sudo -iI następnie gpg --gen-key). Upewnij się, że po uruchomieniu sudo gpg --list-keyszobaczysz pożądane klawisze i linię /root/.gnupg/pubring.gpg.

Mam nadzieję, że to pomaga!