staging.inyokaproject.org

Hallo,

mit folgenden Befehlen konnte ich den gewünschten Schlüssel erzeugen und am gewünschten Ort speichern.

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

Nun würde ich das allerdings gerne mit einem Befehl bewerkstelligen. Z.B. so:

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

Dabei ensteht allerdings die Datei ~/.gnupg/S.dirmgr mit root-Eigentümer. Wie kann ich das verhindern?

Wenn ich | sudo tee ... anhänge, ist die Datei /etc/apt/keyrings/linux-mint-archive.gpg 0 Bytes groß.

Weiterhin würde ich gerne wissen, ob /etc/apt/keyrings/ das dafür passende Verzeichnis ist, oder eher /usr/share/keyrings/. Siehe auch hier. In den manpages finde ich dazu:

$ man apt-key
[.....]
DEPRECATION
       Except for using apt-key del in maintainer scripts, the use of apt-key
       is deprecated. This section shows how to replace existing use of
       apt-key.

       If your existing use of apt-key add looks like this:

       wget -qO- https://myrepo.example/myrepo.asc | sudo apt-key add -

       Then you can directly replace this with (though note the recommendation
       below):

       wget -qO- https://myrepo.example/myrepo.asc | sudo tee
       /etc/apt/trusted.gpg.d/myrepo.asc

       Make sure to use the "asc" extension for ASCII armored keys and the
       "gpg" extension for the binary OpenPGP format (also known as "GPG key
       public ring"). The binary OpenPGP format works for all apt versions,
       while the ASCII armored format works for apt version >= 1.4.

       Recommended: Instead of placing keys into the /etc/apt/trusted.gpg.d
       directory, you can place them anywhere on your filesystem by using the
       Signed-By option in your sources.list and pointing to the filename of
       the key. See sources.list(5) for details. Since APT 2.4,
       /etc/apt/keyrings is provided as the recommended location for keys not
       managed by packages. When using a deb822-style sources.list, and with
       apt version >= 2.4, the Signed-By option can also be used to include
       the full ASCII armored keyring directly in the sources.list without an
       additional file.

$ man sources.list
[.....]
       •   Signed-By (signed-by) is an option to require a repository to pass
           apt-secure(8) verification with a certain set of keys rather than
           all trusted keys apt has configured. It is specified as a list of
           absolute paths to keyring files (have to be accessible and readable
           for the _apt system user, so ensure everyone has read-permissions
           on the file) and fingerprints of keys to select from these
           keyrings. The recommended locations for keyrings are
           /usr/share/keyrings for keyrings managed by packages, and
           /etc/apt/keyrings for keyrings managed by the system operator. If
           no keyring files are specified the default is the trusted.gpg
           keyring and all keyrings in the trusted.gpg.d/ directory (see
           apt-key fingerprint). If no fingerprint is specified all keys in
           the keyrings are selected. A fingerprint will accept also all
           signatures by a subkey of this key, if this isn't desired an
           exclamation mark (!) can be appended to the fingerprint to disable
           this behaviour. The option defaults to the value of the option with
           the same name if set in the previously acquired Release file of
           this repository (only fingerprints can be specified there through).
           Otherwise all keys in the trusted keyrings are considered valid
           signers for this repository. The option may also be set directly to
           an embedded GPG public key block. Special care is needed to encode
           the empty line with leading spaces and ".":

Leider verstehe ich die dort angegebene Unterscheidung "managed by packages" vs. "managed by the system operator" nicht. Kann mir das jemand erklären?

Naja, "managed by package" heisst, dass die Datei aus dem Paket kommt, also auch ggf. überschrieben wird, wenn Du das Paket aktualisierst. Die Datei "managed by admin" wäre dann wohl eher die richtige, um die Einstellungen dauerhaft im System zu haben.

UlfZibis schrieb:

mit folgenden Befehlen konnte ich den gewünschten Schlüssel erzeugen und am gewünschten Ort speichern.

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

Nun würde ich das allerdings gerne mit einem Befehl bewerkstelligen. Z.B. so:

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

Interessant ist, dass bei der 1. Variante eine Datei mit 2,5 kB und bei der 2. mit 2,3 kB entsteht.

Letztere funktioniert auch erst, wenn die Berechtigungen von rw------- auf rw-r--r-- geändert werden.

Doc_Symbiosis schrieb:

Naja, "managed by package" heisst, dass die Datei aus dem Paket kommt, also auch ggf. überschrieben wird, wenn Du das Paket aktualisierst. Die Datei "managed by admin" wäre dann wohl eher die richtige, um die Einstellungen dauerhaft im System zu haben.

Danke Dir!

So hätte ich es auch erst mal interpretiert, aber ich war mir nicht sicher. Beim Linux-Mint-Schlüssel kann man wohl davon ausgehen, dass der nicht durch irgendwelche Pakete geändert wird, hier durch diese, /etc/apt/keyrings/ wäre also hier richtig. Bei WinwHQ kann man dann also davon ausgehen, dass WineHQ den Schlüssel bei Bedarf per Update ändert, oder?

Jetzt bleibt dann nur noch meine Hauptfrage zu beantworten.

UlfZibis schrieb:

mit folgenden Befehlen konnte ich den gewünschten Schlüssel erzeugen und am gewünschten Ort speichern.

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

Korrektur (Rechte und Besitz müssen korrigiert werden):

F=linux-mint-archive.gpg && gpg --no-default-keyring --keyring $F --keyserver keyserver.ubuntu.com --recv-keys A6616109451BBBF2
F=.gnupg/$F && chmod a-w,u+w $F && sudo chown 0:0 $F && sudo mv $F /etc/apt/keyrings/ && sudo apt update  

Hab' nun endlich einen Einzeiler gefunden:

sudo mkdir -p -m g-rwx,o-rwx /root/.gnupg && sudo -H gpg --no-default-keyring --keyring /etc/apt/keyrings/linux-mint-archive.gpg --keyserver keyserver.ubuntu.com --recv-keys A6616109451BBBF2 && sudo apt update 

Hat wer Ideen, wie man die Alternativen besser aufzeigen könnte? Ich lese das gerade und blicke selbst noch nicht durch, daher wollten wir das verbessern.

DJKUhpisse schrieb:

Hat wer Ideen, wie man die Alternativen besser aufzeigen könnte? Ich lese das gerade und blicke selbst noch nicht durch, daher wollten wir das verbessern.

Mein Einzeiler ist Ersatz für:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com A6616109451BBBF2 

Das führt zu einer deprecated Warnung, da Ubuntu nun die policy für Fremdschlüssel geändert hat. Deshalb fände ich es am besten, wenn die dann apt-key einfach auch anpassen würden, statt es einfach zu deprecaten, z.B. durch eine neue Option. Das könnte dann z.B. so aussehen:

sudo apt-key --foreign adv --recv-keys --keyserver keyserver.ubuntu.com A6616109451BBBF2 

So ein Befehl sollte dann automatisch all das erledigen, was ich in meinem Einzeiler manuell zusammen gebaut habe.

EDIT: In gleicher Weise könnte dann auch add-apt-repository angepasst werden, damit man es wieder wie bisher verwenden kann, statt dass man die Quelle manuell basteln muss. Siehe Anwendungsfall.

Vielleicht hat ja jemand Lust, dafür schon mal ein Skript zu basteln, evtl. auf Python-Basis.

Nutzt aber weiterhin apt-key. Ich habe das Problem gelöst, indem ich den Key mit gpg verarbeitet habe und dann eine .gpg in trusted.gpg.d gelegt habe. Dann meckert der nicht mehr. Kann ich gerne raussuchen.

DJKUhpisse schrieb:

Nutzt aber weiterhin apt-key.

Wer ??? Wofür ???

Ich habe das Problem gelöst, indem ich den Key mit gpg verarbeitet habe und dann eine .gpg in trusted.gpg.d gelegt habe. Dann meckert der nicht mehr. Kann ich gerne raussuchen.

Du meinst, apt-key meckert dann nicht mehr, oder wer? Wenn ich es richtig verstanden habe, hast Du so immer noch das "Sicherheitsproblem" drin, welches ja vermieden werden soll, siehe 9324523. Was sagt denn sudo apt update dazu?

Wenn der Schlüssel in der Datei trusted.gpg steht, wird gemeckert. Steht er in einer eigenen Datei unter trusted.gpg.d/iregndwas.gpg, meckert der nicht. Das Problem, dass der Schlüssel nicht einem Repo zugeordnet wird, bleibt.

DJKUhpisse schrieb:

Wenn der Schlüssel in der Datei trusted.gpg steht, wird gemeckert. Steht er in einer eigenen Datei unter trusted.gpg.d/iregndwas.gpg, meckert der nicht. Das Problem, dass der Schlüssel nicht einem Repo zugeordnet wird, bleibt.

Hm, merkwürdig.

Ich hatte da eine andere Erfahrung in Erinnerung. Vielleicht hatte ich diese Empfehlung auch etwas überinterpretiert.

Na umso besser, dann muss man es also nicht ganz so kompliziert machen, und kann alle Fremdschlüssel nach /etc/apt/trusted.gpg.d/ kopieren. Frag' mich nur, wofür dann diese komplizierte "Recommendation" gut ist. Vielleicht für den Fall, wenn Schlüsseldateien von verschiedenen Quellen den gleichen Namen haben – z.B. key.asc ist da sehr beliebt, oder bei wineHQ heißt er winehq.key, hat also die falsche Endung.

Meine Empfehlung für ein an die neuen Regeln angepasstes apt-key würden dann aber immer noch gelten, statt den Befehl veralten zu lassen.

Hier steht, dass /etc/apt/trusted.gpg.d/*.* genauso unsicher ist wie /etc/apt/trusted.gpg → https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html

Und diesen Debian-Artikel verstehe ich auch so → https://wiki.debian.org/DebianRepository/UseThirdParty

Hier steht, dass /etc/apt/trusted.gpg.d/*.* genauso unsicher ist wie /etc/apt/trusted.gpg

Ist es auch, alleine die Verwaltung der Schlüssel wird einfacher, da einzelne Dateien.

DJKUhpisse schrieb:

Hier steht, dass /etc/apt/trusted.gpg.d/*.* genauso unsicher ist wie /etc/apt/trusted.gpg

Ist es auch, alleine die Verwaltung der Schlüssel wird einfacher, da einzelne Dateien.

Ja genau. Insofern verstehe ich dann den Sinn Deines Hinweises nicht, dass man den Schlüssel nach /etc/apt/trusted.gpg.d/ kopieren kann.

DJKUhpisse schrieb:

Hat wer Ideen, wie man die Alternativen besser aufzeigen könnte?

Und jetzt bin ich mir unsicher, wie eigentlich Deine Frage gemeint war und welche Alternativen Du meinst.