GPG-Signaturprüfungen umgehen nur für ein einzelnes Repository


34

Ich habe den folgenden Artikel gelesen: Wie kann ich die GPG-Signaturprüfungen von apt umgehen / ignorieren?

Es wird beschrieben, wie Sie konfigurieren apt, um die Signaturen von Paketen überhaupt nicht zu überprüfen .

Ich möchte jedoch begrenzen die Wirkung dieser Einstellung auf einen einzigen (in diesem Fall lokal gehostet) Repository.

Das heißt: alle offiziellen Repositories sollten die GPG Signaturprüfung wie gewohnt verwenden, außer für den lokalen Repo .

Wie würde ich das machen?

Wenn dies nicht der Fall ist, was wäre der Vorteil (in Bezug auf die Sicherheit), wenn Sie die Pakete während eines automatisierten Builds (einige Metapakete und einige Programme) signieren und dann alles tun, was sicherapt vorgeschrieben ist? Immerhin wäre der Host mit dem Repo dann auch derjenige, auf dem sich der geheime GPG-Schlüssel befindet.


Meiner Meinung nach wäre ein automatisiertes Signieren mit einem Online-Schlüssel zwar alles andere als ideal, aber besser, als überhaupt nicht zu signieren. Es wäre auch viel einfacher einzurichten (es muss nicht jeder Client konfiguriert werden, um auf die Prüfungen zu verzichten), und es wäre viel einfacher, später zu einem besseren Setup überzugehen, wenn Sie dies möchten.
Celada

@ Celada: Ist das eine Meinung (dass es "streng besser" ist) oder gibt es eine Begründung für deine Aussage? Ich frage, weil ich bisher keinen Grund sehen kann, wie dies die Sicherheit oder einen anderen Aspekt verbessern würde. Das einzige Mal, wenn dies etwas vorteilhaft wäre, wäre, wenn ich jemals beabsichtigte, mein Repo zu veröffentlichen, nein?
0xC0000022L

Ich halte diese Meinung rational :-) Wenn das Repository signiert ist, dann müssen zumindest die Bösewichte den Signaturschlüssel bekommen, den Sie wahrscheinlich nur an einer Stelle und wahrscheinlich auf einer Dev-Box aufbewahren, oder zumindest nicht lesbar von der HTTP-Server. Sonst gibt es überhaupt keinen Schutz. Mit anderen Worten, ich möchte nur sagen, dass das Signieren keinen Nachteil hat. Sie können also auch dann unterschreiben, wenn der Vorteil nur gering ist. Und da es einfacher wäre, es einzurichten, würde ich das tun.
Celada

@ Celada: Dies ist ein Repository nur für den lokalen Gebrauch. Wer könnte darauf zugreifen? Anwendungsfall: Ein Host mit Gastcontainern. Sowohl Host als auch Container haben Zugriff. Kein öffentlicher Zugang geplant. Aber ich schätze, ich werde etwas länger auf eine Antwort warten und mich für das ansonsten Unvermeidliche entscheiden (Signieren).
0xC0000022L

Mal sehen, ob jemand die Antwort auf Ihre Frage kennt. Ich weiß nicht, mit welchem ​​Tool Sie das Repo generieren möchten , aber ich empfehle reprepro . Viele der anderen Tools wie dput(oder was auch immer Debian selbst verwendet) sind sehr aufwändig und wirken wie ein gewaltiger Overkill für Ad-hoc-Repo nur auf lokaler Ebene. repreprosorgt dafür, dass das Repo automatisch mit dem richtigen Verzeichnislayout und den richtigen Indexdateien erstellt wird, ohne dass eine große Datenbankserver-Installation erforderlich ist ... und das Ergebnis wird im Grunde genommen ohne zusätzliche Arbeit von Ihrer Seite signiert.
Celada

Antworten:


48

Sie können Optionen einstellen in sources.list:

deb [trusted=yes] http://localmachine/debian wheezy main

Die trustedOption ist das, was von dem GPG - Check macht. Siehe man 5 sources.listfür weitere Einzelheiten.

Anmerkung: Dies wurde in Punkt 0.8.16 ~ exp3 hinzugefügt. Also ist es pfeifend (und natürlich Jessie), aber nicht quetschen.


Vielen Dank. Genau das habe ich gesucht. Ich vertraue 1.0.1ubuntu2.7darauf, dass diese Funktion aufgrund der Versionsnummer bereits verfügbar ist.
0xC0000022L

@ 0xC0000022L ja, das sollte es.
Derobert

Dies ist definitiv die beste Antwort, wenn Sie wiederholt auf ein nicht signiertes Repository zugreifen müssen. Es gibt aktualisierte Antworten auf die andere Frage, die in der ursprünglichen Frage hier verlinkt ist und zeigt, wie dies vorübergehend pro Repository durchgeführt wird.
dragon788

11

Um sicherzustellen, dass bei Verwendung eines unsicheren Repositorys eine Warnung angezeigt wird, verwenden Sie besser allow-insecure = yes (siehe unten)

deb [ allow-insecure=yes ] ...

Interessant, danke für deine Antwort. Ein kleiner, aber wichtiger Unterschied.
0xC0000022L
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.