ubuntuusers.de

@DJKUhpisse:

Warum hast Du denn die tee-Pipe komplett entfernt? Ich wäre dafür, beide Möglichkeiten zu erwähnen.

karzer schrieb:

@DJKUhpisse:

Warum hast Du denn die tee-Pipe komplett entfernt? Ich wäre dafür, beide Möglichkeiten zu erwähnen.

Mit welchem Ziel?

DJKUhpisse schrieb:

Mit welchem Ziel?

Für die Artenvielfalt im Wiki 😉

karzer schrieb:

DJKUhpisse schrieb:

Mit welchem Ziel?

Für die Artenvielfalt im Wiki 😉

Brauchen wir die da wirklich? Dann könnten wir in haufenweise Artikeln 20 Varianten anbieten, Standardkram zu erledigen.

DJKUhpisse schrieb:

Dann könnten wir in haufenweise Artikeln 20 Varianten anbieten, Standardkram zu erledigen.

Ab hier haben wir die 20 Varianten doch mit 10 dividiert, das ist doch nicht zu viel?

Theoretisch ist diese Variante natürlich auch im verlinkten Artikel präsent..

Ich bin da dagegen, denn es verkompliziert die Sache nur - ohne einen wirklichen Nutzen.

Ok, dann kommt der Artikel jetzt so ins Wiki.

Artikel ist im Wiki. Backlinks gerne noch erweitern.

Im verlinkten Artikel von inuxuprising ist das Verzeichnis /usr/share/keyrings/.

• https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html

Dort steht:

So what's the proper, secure way of adding third-party (unofficial) repositories and their OpenPGP signing keys on Debian, Ubuntu, and Linux distributions based on these, like Linux Mint, Pop!_OS, Elementary OS and so on, to replace the deprecated apt-key?

Und dann:

According to the Debian wiki, the key should be downloaded over HTTPS to a location only writable by root, for example /usr/share/keyrings

Auch fostips gibt /usr/share/keyrings/ als Verzeichnis für Fremdquellen-Schlüssel an:

• https://fostips.com/apt-key-deprecated-right-way-add-repository/

Oder mal bei Canonical direkt nachschauen?

• https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333

Dort wird es bei Mandatory Signed-By gezeigt: /usr/share/keyrings/ als Ausblick auf Ubuntu Version 24.04 im Rahmen vom DEB822 Source List Format. Hat jemand einen direkten Draht zu Canonical und kann mal anfragen was Canoncal zum Verzeichnis für die Schlüssel sagt? Bleibt es bei /usr/share/keyrings/?

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.

• https://learn.microsoft.com/en-us/microsoftteams/get-clients?tabs=Linux#tabpanel_1_Linux

Die Microsoft-Webseite zeigt diese Information nur an, wenn Javascript und Cookies erlaubt werden. Hier zum Beispiel und zur Bequemlichkeit fürs Terminal mal rüberkopiert:

curl https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft-archive-keyring.gpg

sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft-archive-keyring.gpg] https://packages.microsoft.com/repos/ms-teams stable main" > /etc/apt/sources.list.d/teams.list'

sudo apt update
sudo apt install teams

Ich verwende kein Microsoft Teams, aber im Zuge der Corona-Geschichte hat sich solch eine Anwendung wohl durchaus verbreitet.

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.

Um M$-Teams auf Linux zu installieren muss nur das Paket teams_1.5.00.10453_amd64.deb heruntergeladen und installiert werden. Es muss kein Schlüssel manuell installiert werden. D.h., der Schlüssel wird vom Paket verwaltet. In dem Fall ist dann /usr/share/keyrings/ auch das richtige Verzeichnis.

UlfZibis schrieb:

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.

Um M$-Teams auf Linux zu installieren muss nur das Paket teams_1.5.00.10453_amd64.deb heruntergeladen und installiert werden. Es muss kein Schlüssel manuell installiert werden. D.h., der Schlüssel wird vom Paket verwaltet. In dem Fall ist dann /usr/share/keyrings/ auch das richtige Verzeichnis.

Falsch!

Schau mal in das teams_1.5.00.10453_amd64.deb Paket hinein, das ist ganz trickreich, im postinst Script ist der ASCII armored Key enthalten, der wird dann vom postinst Script in den /etc/apt/trusted.gpg.d/microsoft.gpg GPG-Key umgewandelt.

file /etc/apt/trusted.gpg.d/microsoft.gpg

/etc/apt/trusted.gpg.d/microsoft.gpg: OpenPGP Public Key Version 4, Created Wed Oct 28 23:21:48 2015, RSA (Encrypt or Sign, 2048 bits); User ID; Signature; OpenPGP Certificate

Dort bleibt der dann auch wenn Microsoft Teams komplett mit purge entfernt wird. In der /etc/apt/sources.list.d/teams.list Datei hingegen ist kein signed-by Eintrag.

cat /etc/apt/sources.list.d/teams.list 

### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb [arch=amd64] https://packages.microsoft.com/repos/ms-teams stable main

Es ist also genau das falsche Verhalten. Genau das, das sicherheitsbedenklich ist, bei Drittanbieter Repositories.

Bequem ist es aber, so wie es Microsoft für seine Teams Kunden macht. Guckt ja kaum einer so genau nach.

Man könnte wohl auch sagen: andersherum ist es richtig. Wer hat bloß diese Verwirrung im WineHQ gestiftet? Ich wars nicht.

Noch ein Beispiel:

das von vielen gescholtene Nvidia macht es deutlich richtiger, Nvidia bietet zwar ein DEB-Paket an, welches den Schlüssel und die Source List installiert, das ist aber ein dezidiertes Paket für den Schlüssel und die Source List für CUDA. In diesem Nvidia CUDA Repository sind auch properitären nvidia-driver für Ubuntu enthalten. Es ist ganz klar ein Drittanbieter Repository:

• https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/

Die Anleitung für den Nvidia CUDA Repository Schlüssel gibt es dort zu lesen vom Drittanbieter:

• https://forums.developer.nvidia.com/t/notice-cuda-linux-repository-key-rotation/212771

Schaut man in das cuda-keyring_1.0-1_all.deb hinein, dann kann man im postinst Script lesen, wie es den alten Schlüssel aus dem Schlüsselring entfernt:

#! /bin/sh

set -e

case "$1" in
    configure)
        keyexists="$(GNUPGHOME=/dev/null gpg /etc/apt/trusted.gpg 2>/dev/null | grep -i 7fa2af80)" || true
        if [ ! -f "/etc/apt/trusted.gpg" ] || [ ! "$keyexists" ]; then
            removeKey="sudo apt-key del 7fa2af80"
            cat <<EOM

A deprecated public CUDA GPG key appear to be installed.
To remove the key, run this command:
$removeKey

EOM
        fi
        ;;
esac



exit 0

Im data Archiv innerhalb des DEB-Pakets findet sich dann die Verzeichnishierachie abgebildet, wohin es die Source List cuda-ubuntu2204-x86_64.list installiert:

ls -1 /etc/apt/sources.list.d/cuda-ubuntu2204-x86_64.list 

/etc/apt/sources.list.d/cuda-ubuntu2204-x86_64.list

Wo es das Pinning setzt, damit die CUDA Pakete etwas mehr Priorität haben:

ls -1 /etc/apt/preferences.d/cuda-ubuntu2204 

/etc/apt/preferences.d/cuda-ubuntu2204

Und wo der Schlüssel für das Drittanbieter Repositry hingehört:

ls -1 /usr/share/keyrings/cuda-archive-keyring.gpg 

/usr/share/keyrings/cuda-archive-keyring.gpg

Die Metapakete für den nvidia-driver machen das nicht. Das dezidierte Schlüsselpaket für CUDA hingegen macht es richtig, und setzt, wie es für 2024 geplant ist als Pflicht für jedes Repository, das "signed-by=/usr/share/keyrings/" in die Source List für das Drittanbieter Repository. Das DEB822 Source List Format ist es noch nicht, denn das kollidiert ja noch mit den Verwaltungswerkzeugen der Ubuntu User, wie etwa software-properties, Ubuntu-release-upgrader, command-not-found, aptdaemon, ansible, apt-clone, apturl, Curtin, Cloud-init.

cat /etc/apt/sources.list.d/cuda-ubuntu2204-x86_64.list 
deb [signed-by=/usr/share/keyrings/cuda-archive-keyring.gpg] https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /

Frage doch mal bitte eine dritte Person, also weder ich noch UlfZibis bei Canonical nach, wo die Schlüssel für das "signed-by=" der Source List nun hingehören. Wäre ja ungeschickt, wenn dieses Forum, das zwar im deutschsprachigen Raum reichweitenstark sein mag, womöglich noch Canonical und dem Rest der Welt in Sachen Ubuntu zuwider läuft.

trollsportverein schrieb:

Dort bleibt der dann auch wenn Microsoft Teams komplett mit purge entfernt wird. In der /etc/apt/sources.list.d/teams.list Datei hingegen ist kein signed-by Eintrag.

cat /etc/apt/sources.list.d/teams.list 

### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb [arch=amd64] https://packages.microsoft.com/repos/ms-teams stable main

Es ist also genau das falsche Verhalten. Genau das, das sicherheitsbedenklich ist, bei Drittanbieter Repositories.

Es ist also noch schlimmer, als ich dachte.

Dafür sind wir ja Linux-Nutzer, weil wir wissen, wo man bei WinzigWeich dran ist.

trollsportverein schrieb:

Frage doch mal bitte eine dritte Person, also weder ich noch UlfZibis bei Canonical nach, wo die Schlüssel für das "signed-by=" der Source List nun hingehören.

Paket-verwaltete Schlüssel –> /usr/share/keyrings/ CUDA macht es also richtig.

Manuell verwaltete Schlüssel –> /etc/apt/keyrings/ WineHQ macht es demnächst also auch richtig.

Wäre ja ungeschickt, wenn dieses Forum, das zwar im deutschsprachigen Raum reichweitenstark sein mag, womöglich noch Canonical und dem Rest der Welt in Sachen Ubuntu zuwider läuft.

Genau so sehe ich es auch.