Könnte mal bitte ein Teamviewer Nutzer mit Jammy Jellyfish überprüfen, ob im Artikel auch noch für Jammy Jellyfish der Installationshinweis stimmt? Ich habe Bedenken dass es bei apt-key auf Jammy Jellyfish hakeln könnte.
TeamViewer
Anmeldungsdatum: Beiträge: 2627 |
|
Anmeldungsdatum: Beiträge: 2726 |
Ich habe die DEB-Datei immer mit GDebi installiert, da muss man nicht mit |
Anmeldungsdatum: Beiträge: 2627 |
Schlüssel für das WineHQ Repository und auch das CUDA Repository werden in /usr/share/keyrings/ abgelegt, daher fände ich es logisch, dass dort auch dann der entsprechende Schlüssel für TeamViewer abgelegt würde. So in etwa würde es mir vorschweben: wget -O- https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc | gpg --dearmor | sudo tee /usr/share/keyrings/teamviewer.gpg &> /dev/null sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/teamviewer.gpg] http://linux.teamviewer.com/deb stable main" >> /etc/apt/sources.list.d/teamviewer.list' Das ist aber nicht getestet, sondern einfach aus den Erkenntnissen mit WineHQ Repository und CUDA Repository abgeleitet. Das TeamViewer2017.asc ist ebenfalls ein GnuPG v1 PUBLIC KEY wie es auch der alte CUDA Repository Schlüssel war, den man auf diese Art einbauen musste. |
Anmeldungsdatum: Beiträge: 2726 |
Das gilt für Schlüssel, die durch das Paket selbst verwaltet werden und theoretisch durch dieses auch verändert werden können. Dies trifft auf den manuell hinzugefügten Schlüssel TeamViewer2017.asc aber nicht zu, weshalb er IMO nach /etc/apt/keyrings/ gehört. |
Anmeldungsdatum: Beiträge: 2627 |
Bitte noch mal genau durchlesen, es geht nicht darum den Schlüssel in /etc/apt/trusted.gpg.d/ unterzubringen! Das unterbringen in /etc/apt/trusted.gpg.d/, oder hinzufügen in den großen Schlüsselbund in /etc/apt/trusted.gpg will der askubuntu Nutzer Askeli vermeiden. Was auch vermieden werden soll, wenn man den askubuntu Thread als Vorlage nimmt, dann ist es das unterbringen vom Schlüssel im Nutzer-Home-Verzeichnis, da dies Manipulationen Tür und Tor öffnen könnte. Hier mehr zu lesen: Hier der wesentliche Satz daraus:
|
Anmeldungsdatum: Beiträge: 2726 |
Bezüglich des richtigen Verzeichnisses gibt es wohl Meinungsverschiedenheiten, Meine Meinung wurde aber auch hier vertreten. Klar ist, dass er nicht nach /etc/apt/trusted.gpg.d/ oder /etc/apt/trusted.gpg gehört. |
Anmeldungsdatum: Beiträge: 2627 |
Das alte Mutterschiff Debian hat auch das /usr/share/keyrings/ Verzeichnis für die nicht global trusted Repositories auserkoren: Nvidia nutzt ebenfalls das /usr/share/keyrings/ Verzeichnis für den CUDA Repository Schlüssel und das WineHQ macht es auch so. Für Kompatibilität und Übersicht behalten, dürfte es wohl besser sein, das /usr/share/keyrings/ Verzeichnis zu nutzen, das bereits von Debian, vom WineHQ und Nvidia CUDA Repositories für die nicht global trusted Schlüssel genutzt wird. |
Anmeldungsdatum: Beiträge: 2726 |
Mittlerweile, zumindest auf 22.04, produziert GDebi bei anschließend ausgeführtem W: https://linux.teamviewer.com/deb/dists/stable/InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details. W: https://repo.skype.com/deb/dists/stable/InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details. Tja, die Maintainer der Pakete haben leider noch keine Zeit gefunden, um sich an die neuen Bedingungen auf Debia/Ubuntu anzupassen. Zumindest WinzigWeich hat ja zur Zeit bedeutungsschwangere Welt-Aufgaben zu lösen. Interessant ist, dass Google Chrome scheinbar einen von Debian/Ubuntu akzeptierten Schlüssel verwendet, denn da kommt keine Warnung, obwohl der unter /etc/apt/trusted.gpg.d/ abgelegt ist. |
Anmeldungsdatum: Beiträge: 2726 |
Bis auf die Wahl des Verzeichnisses würde ich Dir zustimmen. Die von WineHQ vorgeschlagene Installationsweise ist leider fehlerhaft, siehe: https://bugs.winehq.org/show_bug.cgi?id=53356 |