UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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?
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4427
Wohnort: Göttingen
|
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
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18018
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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.
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18018
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18018
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18018
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
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.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3082
Wohnort: Köln
|
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.
|