staging.inyokaproject.org

UlfZibis schrieb:

Vielleicht so:

sudo -H gpg --fetch-keys 'http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xc77205f7194a3e1abe2df9a4b7b9c16f2667ca5c' -o /etc/apt/keyrings/my-dream-key.gpg 

Nein, das geht nicht.

Man kann die Option --output mit --fetch-keys nicht verwenden, das habe ich schon ausprobiert.

DJKUhpisse schrieb:

gpg --no-default-keyring --keyring /etc/apt/keyrings/linux-mint-archive.gpg --keyserver keyserver.ubuntu.com --recv-keys A6616109451BBBF2

Sollte dann nicht --keyring auch bei einer normalen URL funktionieren?

Ja, das geht.

DJKUhpisse schrieb:

Sollte dann nicht --keyring auch bei einer normalen URL funktionieren?

Könnte sein. Aber welchen Sinn soll es machen, den Schlüssel noch in einen "keyring" zu verpacken, statt ihn einfach nur mittels -o abzulegen, vor allem, wenn die vom Repo-Anbieter vorgegebene Datei evtl. schon ein "keyring" ist?

karzer schrieb:

Man kann die Option --output mit --fetch-keys nicht verwenden, das habe ich schon ausprobiert.

Vielleicht kann --fetch-keys ja mit --keyring zusammen verwendet werden. Der Plural von --fetch-keys deutet ja schon an, dass es auch um mehrere Schlüssel gehen kann. Da macht es dann Sinn, sie in einem "keyring" zu bündeln.

trollsportverein schrieb:

Es hat mir keine Ruhe gelassen, so kann ich nicht schlafen. Also habe ich nochmal mein Google-Kung-Fu benutzt und fand auch bei Microsoft für die Installation und aktuell halten von Microsoft Teams in der offiziellen Dokumentation das Verzeichnis für die Schlüssel unter /usr/share/keyrings/ vor.

Der Schlüssel für Skype für Linux wird mit der Standard-Installation sogar in /etc/apt/trusted.gpg abgelegt, was eine Warnung bei sudo apt update auslöst.

Ja auf M$ können wir wahrscheinlich ewig warten, bis die das ändern. Ist doch praktisch für die, so können sie den Weg für den sogenannten Bundes-Trojaner frei halten.

Deshalb möchte ich vorschlagen, in den Artikel eine Anleitung aufzunehmen, wie man falsch abgelegte Schlüssel an die richtige Stelle bugsiert. Für Skype sieht das z.B. so aus (erst mal den Fingerprint kontrollieren):

apt-key finger  ## In der Ausgabe nach dem Schlüssel für Skype suchen.
sudo apt-key -o /etc/apt/keyrings/skype-archive.asc export "D404 0146 BE39 7250 9FD5  7FC7 1F30 45A5 DF75 87C3"
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/skype-archive.asc] https://repo.skype.com/deb stable main" | sudo tee /etc/apt/sources.list.d/skype-stable.list
sudo apt-key --keyring /etc/apt/trusted.gpg del "D404 0146 BE39 7250 9FD5  7FC7 1F30 45A5 DF75 87C3" 

Wenn man es ganz toll machen will, kann man den Schlüssel vorher auch noch "entwaffnen" mit:

sudo -H gpg --dearmor -o /etc/apt/keyrings/skype-archive.gpg /etc/apt/keyrings/skype-archive.asc
sudo rm /etc/apt/keyrings/skype-archive.asc 

... und dann die Endung .gpg in /etc/apt/sources.list.d/skype-stable.list verwenden.

TeamViewer hat das mit dem neuesten Update vor einer Woche halb-seiden korrigiert. Der Schlüssel wurde aus /etc/apt/trusted.gpg entfernt, und immerhin schon mal nach /usr/share/keyrings/teamviewer-keyring.gpg verlagert. (Reste befinden sich noch im Backup: /etc/apt/trusted.gpg~. Die haben also auch den Debian-Artikel nicht sorgfältig gelesen.

Hallo,

Deshalb möchte ich vorschlagen, in den Artikel eine Anleitung aufzunehmen,

Nee, wäre wenn ein eigenes Howto.

... wie man falsch abgelegte Schlüssel an die richtige Stelle bugsiert.

Dann sollte der neue Artikel / das neue Howto damit beginnen, dass erklärt wird warum Ort $FOO falsch wird.

Ist doch praktisch für die, so können sie den Weg für den sogenannten Bundes-Trojaner frei halten.

Ja, aber dagegen hilft doch bekanntlich schon seit mehreren Jahren, dass man sich einen Aluhut bastelt und aussetzt, bevor man seinen Rechner anmacht...

Gruß, noisefloor

noisefloor schrieb:

Deshalb möchte ich vorschlagen, in den Artikel eine Anleitung aufzunehmen,

Nee, wäre wenn ein eigenes Howto.

Der Artikel ist allgemein "Schlüsselverwaltung". Daher wäre es inhaltlich passend, zu beschreiben, wie man die Schlüssel verschiebt.

... wie man falsch abgelegte Schlüssel an die richtige Stelle bugsiert.

Dann sollte der neue Artikel / das neue Howto damit beginnen, dass erklärt wird warum Ort $FOO falsch wird.

Kann dann hier rein, da ist eh schon die Problematik erläutert.

Ist doch praktisch für die, so können sie den Weg für den sogenannten Bundes-Trojaner frei halten.

Ja, aber dagegen hilft doch bekanntlich schon seit mehreren Jahren, dass man sich einen Aluhut bastelt und aussetzt, bevor man seinen Rechner anmacht...

Ist in der Artikeldiskussion OT.

Wieso behauptet dieser Artikel:

Bisher wurden diese mit apt/apt-key verwaltet, was jedoch veraltet ist und seit Ubuntu 22.04 nicht mehr vollumfänglich unterstützt wird.

und

Ab Ubuntu 22.04 funktioniert die veraltete Methode mit apt-key nicht mehr.

?

Das stimmt doch gar nicht! Aus der Manpage von apt-key:

apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.

Also sollte es doch mit Ubuntu 22.04 wie bisher funktionieren. Von seiner Verwendung wird nur abgeraten, weil es bei Ubuntu-Versionen nach 22.04 nicht mehr verfügbar sein soll. Oder stimmt die Handbuchseite nicht?

kB schrieb:

Wieso behauptet dieser Artikel:

Bisher wurden diese mit apt/apt-key verwaltet, was jedoch veraltet ist und seit Ubuntu 22.04 nicht mehr vollumfänglich unterstützt wird.

und

Ab Ubuntu 22.04 funktioniert die veraltete Methode mit apt-key nicht mehr.

?

Das stimmt doch gar nicht! Aus der Manpage von apt-key:

apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.

Also sollte es doch mit Ubuntu 22.04 wie bisher funktionieren. Von seiner Verwendung wird nur abgeraten, weil es bei Ubuntu-Versionen nach 22.04 nicht mehr verfügbar sein soll. Oder stimmt die Handbuchseite nicht?

Stimmt so nicht. apt-key ist noch da, aber man kann damit keine Schlüssel mehr hinzufügen bzw. funktionieren diese halt nicht.

DJKUhpisse schrieb:

[…] Stimmt so nicht.

Drücke Dich bitte qualifizierter und differenzierter aus! Vollzitate sind nur ganz selten sinnvoll und deshalb auch bei UbunuUsers.de verpönt. Was genau stimmt an meinen Ausführungen nicht?

apt-key ist weiterhin dabei, aber wenn man darüber Schlüssel hinzufügt, akzeptiert apt-get diese nicht mehr. Daher ist apt-key unter 22.04 nicht für das Hinzufügen von Schlüsseln nutzbar.

Hallo,

Folgendes habe ich im Debian Wiki dazu gelesen:

[..] The key MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add.

noisefloor schrieb:

Dann sollte der neue Artikel / das neue Howto damit beginnen, dass erklärt wird warum Ort $FOO falsch wird.

Das könnte in der Tat noch verbessert werden. Hier schon mal ein rudimentärer Ansatz:

Das problematische daran ist, dass dabei der Installations-Schlüssel von Microsoft im generellen Schlüsselbund /etc/apt/trusted.gpg abgelegt wird, wodurch es dem Fremdanbieter möglich ist, offizielle Ubuntu-Pakete mit eigenen zu überschreiben (die z.B. eine Schnittstelle für Trojaner enthalten können). Um dies zu verhindern, sollte der Schlüssel im für Fremdschlüssel vorgesehenen Verzeichnis abgelegt werden.

Hallo,

korrigiert mich, wenn ich falsch liege, aber: ein kompromittierter Schlüssel ist doch nur die halbe Miete, weil der muss doch nichts desto trotz zu den Paketquellen passen. D.h. wenn man dem Nutzer "falsche" Pakete unterjubeln will, muss man doch auch noch die zugehörige Quelle kompromittieren? Und ein kompromittierter Schlüssel alleine ermöglicht doch auch noch nicht, dass ein Paket z.B. von source.of.all.evil.org statt z.B. aus den Canonical Quellen gezogen wird.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

korrigiert mich, wenn ich falsch liege, aber: ein kompromittierter Schlüssel ist doch nur die halbe Miete, weil der muss doch nichts desto trotz zu den Paketquellen passen. D.h. wenn man dem Nutzer "falsche" Pakete unterjubeln will, muss man doch auch noch die zugehörige Quelle kompromittieren? Und ein kompromittierter Schlüssel alleine ermöglicht doch auch noch nicht, dass ein Paket z.B. von source.of.all.evil.org statt z.B. aus den Canonical Quellen gezogen wird.

Richtig, aber die meisten Quellen nutzen http und damit ist Spoofing kinderleicht möglich. Der einzige Schutz dagegen ist der Schlüssel für die Signatur der Pakete.

Die Änderung hier soll verhindern, dass jemand IP-Spoofing mit http://archive.ubuntu.com und seinem Schlüssel der manuell auf dem PC für eine andere Quelle eingerichtet wurde, machen kann.

Hallo,

bzgl. "kinderlich": korrigier' mich, wenn ich falsch liege, aber ist IP-Spoofing nicht eine "man in den middle" Attacke, d.h. man braucht irgendwie irgendwo Zugriff auf den (unverschlüsselten) Netzwerkverkehr?

Gruß, noisefloor