Sprawdzanie zaufania podpisu za pomocą gpg?

Chcemy używać sygnatur gpg do weryfikacji niektórych aspektów naszych narzędzi do zarządzania konfiguracją systemu. Ponadto chcielibyśmy zastosować model „zaufania”, w którym poszczególne klucze sysadmin są podpisywane za pomocą głównego klucza podpisującego, a następnie nasze systemy ufają temu kluczowi głównemu (i używają „sieci zaufania” do sprawdzania poprawności podpisów przez naszych sysadminów).

Daje nam to dużą elastyczność, na przykład możliwość łatwego odwołania zaufania do klucza, gdy ktoś odchodzi, ale mamy problem. Chociaż gpgpolecenie powie ci, czy klucz jest niezaufany, nie wydaje się, aby zwracał kod wyjścia wskazujący na ten fakt. Na przykład:

# gpg -v < foo.asc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header: 
gpg: original file name=''
this is a test
gpg: Signature made Fri 22 Jul 2011 11:34:02 AM EDT using RSA key ID ABCD00B0
gpg: using PGP trust model
gpg: Good signature from "Testing Key <someone@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: ABCD 1234 0527 9D0C 3C4A  CAFE BABE DEAD BEEF 00B0
gpg: binary signature, digest algorithm SHA1

To, na czym nam zależy, to:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Kod wyjścia zwracany przez gpg w tym przypadku wynosi 0, pomimo niepowodzenia zaufania:

# echo $?
0

Jak sprawić, by gpg zawiódł w przypadku, gdy coś jest podpisane niezaufanym podpisem?

Widziałem kilka sugestii, że gpgvpolecenie zwróci odpowiedni kod wyjścia, ale niestety gpgvnie wie, jak pobrać klucze z serwerów kluczy. Wydaje mi się, że możemy przeanalizować dane wyjściowe statusu (używając --status-fd) gpg, ale czy jest lepszy sposób?

To właśnie skończyło się na:

#!/bin/sh

tmpfile=$(mktemp gpgverifyXXXXXX)
trap "rm -f $tmpfile" EXIT

gpg --status-fd 3 --verify "$@" 3> $tmpfile || exit 1
egrep -q '^\[GNUPG:] TRUST_(ULTIMATE|FULLY)' $tmpfile

Poszukuje informacji o zaufaniu, które zostaną gpgwyświetlone --status-fd. Skrypt kończy działanie z błędem w obecności niezaufanego podpisu (lub niepoprawnego / brak podpisu):

$ sh checksig sample.sh.bad 
gpg: Signature made Mon 24 Jun 2013 11:42:58 AM EDT using RSA key ID DCD5C569
gpg: Good signature from "Test User <testuser@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6FCD 3CF0 8BBC AD50 662E  5070 E33E D53C DCD5 C569
$ echo $?
1

Skrypt kończy się bez błędu w obecności prawidłowego, zaufanego podpisu:

$ sh checksig sample.sh.good
gpg: Signature made Mon 24 Jun 2013 11:38:49 AM EDT using RSA key ID 5C2864A8
gpg: Good signature from "Lars Kellogg-Stedman <...>"
$ echo $?
0

Pozwól, że spróbuję podzielić problem:

Pierwszy problem wydaje się, że klucz, na którym testujesz, jest niezaufany.

gpg -v < test.txt.asc 
gpg: armor header: Version: GnuPG v1.4.11 (GNU/Linux)
gpg: original file name='test.txt'
this is a test
gpg: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpg: using PGP trust model
gpg: Good signature from "John Doe <jdoe@noemail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5DD8 216D ADB1 51E8 4326  3ACA 1DED BB72 FE1B 770E
gpg: binary signature, digest algorithm SHA1

Zakładałem, że jest to celowe ... ale zanim przejdziemy do naprawy, pozwól mi zasugerować użycie gpgv zamiast gpg -v ? Zobaczysz dlaczego za chwilę:

$ gpgv < test.txt.asc 
gpgv: keyblock resource `/user/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Can't check signature: public key not found

$ echo $?
2

Bez klucza, bez zaufania ... Nie, importujemy klucz do zaufanych kluczy.gpg

$ gpg --no-default-keyring --keyring trustedkeys.gpg --import jdoe_pub.gpg
gpg: keyring `/user/.gnupg/trustedkeys.gpg' created
gpg: key FE1B770E: public key "John Doe <jdoe@noemail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
$ gpgv < test.txt.asc 
gpgv: Signature made Thu 11 Aug 2011 09:09:35 PM EST using RSA key ID FE1B770E
gpgv: Good signature from "John Doe <jdoe@noemail.com>"

$ echo $?
0

Mam nadzieję, że to pomoże

Przychodzą mi na myśl dwie opcje (inne niż analiza wyników).

Szybkim i brudnym sposobem byłoby uruchomienie zarówno gpg i gpgv. Pierwsze uruchomienie gpgupewni się, że klucz został pobrany z serwera kluczy, a następnie gpgvpoda odpowiedni kod powrotu.

Bardziej eleganckim, kontrolowanym sposobem (choć wymagałoby to więcej pracy) byłoby użycie biblioteki gpgme do weryfikacji podpisu. Jest to biblioteka C, choć istnieją opakowania dla Perla , PHP , Pythona i Ruby . (Python ma dość niski poziom, podczas gdy Ruby ma jakieś abstrakcje na wyższym poziomie, nie jestem pewien co do Perla lub PHP).

Wydaje się, że biblioteka GPGME rozmawia z serwerami kluczy, gdy z niej korzystam, ale chciałbyś to potwierdzić. Pisałem trochę kodu, który wykorzystuje bibliotekę Ruby gpgme (wyszukiwanie verifyi verified_ok?kodu, który weryfikuje podpis, i dla sig_output_linesjakiegoś kodu, który działa, czy podpis jest zaufany).

Co powiesz na migrację konfiguracji systemu do narzędzia takiego jak Puppet lub Chef ?

Chociaż nie jest to trywialna ilość pracy, szefie kuchni (nie korzystałem z Puppet) musisz utworzyć konta użytkowników (i generowane są klucze pub / private). Chociaż nie uniemożliwia to modyfikowania lokalnych plików na serwerze, szef-klient jest uruchamiany okresowo i nadpisuje ich zmiany przy następnym uruchomieniu. (Domyślnie występują okresowe cykliczne przebiegi).