SaThaRiel schriebIm Moment akzeptiere ich einfach alle Keys ohne wirklich zu wissen, ob der Signierer ein TU ist und ob der Key stimmt.
Da würde sich auch anbieten, sich etwas mit Signaturen und Schlüssel(managment) zu beschäftigen.

Kurz evtl. zur "Erhellung":
a) Die Fragen bei den normalen pacman -Syu Vorgängen, daß z.B. Pierres Key nicht vorhanden ist und ob man diesen runterladen will:
Das hat (noch) nichts mit Vertrauen o.ä. zu tun, man fügt durch Y/J lediglich diesen Schlüssel zu seinem (bzw. pacmans) Schlüsselring hinzu. Das ist die Vorraussetzung, damit mit dem Schlüssel überhaupt gearbeitet werden kann. Z.B. habe ich in meinem Keyring für Emails ca. 8000 Schlüssel anderer Leute, daß heißt aber nicht das ich diesen Schlüssel "traue" sondern eben nur daß mir die Schlüssel schon bekannt sind wenn z.B. eine signierte Email ankommt.

b) Spannend wird es erst im Zusammenhang mit den MasterKeys. Wenn man sich z.B. Pierres Schlüssel (seinen eigenen, 9741E8AC, das ist *nicht* der MasterKey von Pierre! Mit seinem eigenen signiert er seine erstellten Pakete): 
# pacman-key --list-sigs 9741E8AC
pub   2048R/9741E8AC 2011-04-10
uid                  Pierre Schmitz <pierre@archlinux.de>
sig     P    65D0FD58 2011-04-11  [User-ID nicht gefunden]
sig          FECE664E 2011-11-12  [User-ID nicht gefunden]
sig 3        9741E8AC 2011-04-10  Pierre Schmitz <pierre@archlinux.de>
sig          6AC6A4C2 2011-11-18  Pierre Schmitz (Arch Linux Master Key) <pierre@master-key.archlinux.org>
sig          824B18E8 2011-11-19  Thomas Bächler (Arch Linux Master Key) <thomas@master-key.archlinux.org>
sig          4C7EA887 2011-11-25  Ionut Biru (Arch Linux Master Key) <ionut@master-key.archlinux.org>
sig          CDFD6BB0 2011-12-01  Dan McGee (Arch Linux Master Key) <dan@master-key.archlinux.org>
sig          8E4B1A25 2011-11-13  [User-ID nicht gefunden]
sig          FFF979E7 2011-12-05  Allan McRae (Arch Linux Master Key) <allan@master-key.archlinux.org>
sub   2048R/54211796 2011-04-10
sig          9741E8AC 2011-04-10  Pierre Schmitz <pierre@archlinux.de>
Hier sieht man, daß die Echtheit seines Schlüssels mindestens von 3 der Archlinux Master Keys bestätigt/(gegen)signiert sind. Die fünf Master Keys hat man ja laut Wiki-Artikel vorher überprüft(Fingerprint) und diesen ein gewisses Vertrauen(trust) ausgesprochen (mindestens Sufe marginales Vertrauen).
//Edit: die Ausgaben oben mit "[User-ID nicht gefunden]" bei mir bedeuten, daß ich diese Schlüssel - die ebenfalls Pierres Schlüssel bestätigen - nicht an meinem Schlüsselring habe. Das kann z.B. ein Schlüssel eines Freundes oder der Uni/Firma sein....

Beim Prüfen der signierten Pakete durch pacman wird Pierres Schlüssel nun deswegen vertraut *weil* er eben von mind. 3 der von mir als vertrauenswürdigen MasterKeys bestätigt wird. Ich persönlich muß seinem Key nicht unbedingt noch extra das Vertrauen aussprechen oder ihn mit dem lokalen "Pacman Keychain Master Key <pacman@localhost>"(erstellt durch pacman-key --init) signieren. Das "Vertrauensgebäude" ist für pacman durch die MasterKeys gegeben.

Anders wäre es dann bei Schlüsseln für fremde Repositorien, die eben nicht durch die offiziellen MasterKeys gegensigniert/bestätigt sind. Diese muß ich dann extra überprüfen(Fingerprint) und eine Stufe des Vertrauens aussprechen. Das ist dann alles mit pacman-key möglich. (ich selbst habe diesen Fall noch nicht, die Praxistauglichkeit wird sich dann rausstellen).

//Edit2, weil ich's witzig finde: man könnte sich ja Updates/Pakete auch per EPost-Brief schicken lassen, evtl. schreibt jemand eine Schnittstelle für pacman... <g> Das wäre ja - laut Post - die ultimative Sicherheit... SCNR!

//Edit3: Zum "Aufwand", den man mit den MasterKeys betreiben muß:
Irgendwo muß bei einem elektronischen Vertrauensgebilde das Vertrauen auch beginnen. Die Lösung mit den Master Keys (und ja, mehrere ist sinnvoll, nicht nur z.B. einer per Repo o.ä.) finde ich eigentlich ok. Wenn man das ganze "Signieren von Paketen fehlt!" ernst genommen hat, dann muß man eben diese 5 Keys gewissenhaft überprüfen. Also wirklich per Fingerprint *und* ich muß mich drauf verlassen, daß die MasterKey-Webseite über https mit den Fingerprints die richtige ist. Hier beginnt Vertrauen...
Die Masterkeys als pacman-Paket (evtl. mit automatischem Vetrauen o.ä.) "bequem" runterzuladen macht zumindest über die diversen Mirrors keinen Sinn (woher will ich wissen daß das MasterKey-Paket vom Mirror kernel.org nicht gefälscht ist...). Bei Neuinstallation steht man so wohl (ungetestet) erstmal vor einem Henne<->Ei-Problem... Das kann wohl zuverlässig wohl nur über vorbereitete Installationsmedien geleistet werden.
Ein Paket mit den Schlüsseln der Devs/TUs kann/wird es wohl schon irgendwan geben, so würde bei der Arbeit mit pacman die o.a. Nachfrage, ob Key xy runtergeladen werden soll, entfallen.
Pierre schriebDu kannst zunächst die Verifizierung deaktivieren. Füge dazu "SigLevel = Never" in den "[options]"-Bereich von pacman.conf ein.
Das habe ich auch gemacht, damit ich updaten konnte.
Aber was genau muss ich machen, damit das Update bei aktiver Verifizierung funktioniert.
Ich raffe es irgendwie überhaupt nicht, was es mit den Keys und der Signierung auf sich hat.
Ich hoffe, mir kann das jemand "anfängerfreundlich" erklären.
Wenn folendes zu einem Key steht:
This key was revoked on 2011-11-19 by RSA key 824B18E8 Thomas Bächler (Arch Linux Master Key) <thomas@master-key.archlinux.org>
sub  1024R/AAE53976  created: 2011-11-19  revoked: 2011-11-19  usage: E   
This key was revoked on 2011-11-19 by RSA key 824B18E8 Thomas Bächler (Arch Linux Master Key) <thomas@master-key.archlinux.org>
sub  2048R/96A8F3F2  created: 2011-11-19  revoked: 2011-11-19  usage: A
Hat das was zu sagen?
GerBra schriebGegenfrage (ich denke, so kommen wir weiter):
Wo hakt/hängt es denn, wenn du dich an den Wiki-Beitrag https://wiki.archlinux.de/title/Pacman-key hältst?
Mir ist das alles zu hoch. Ich weiß echt nicht, was ich machen soll, da es offensichtlich keine allgemeine Vorgehensweise gibt. Die weiterführenden/erklärenden Links sind alle auf englisch, wessen ich nicht mächtig bin.
Ergo, ich lass es unsigniert.
Aber das wichtige steht doch dort:

1. # pacman-key --init
2. Du holst dir die Master-Keys: https://www.archlinux.org/master-keys/
Für jeden Key einmal ein:

# pacman-key -r <id>

Die Id ist das was bei '0x6AC6A4C2' etwa, nach dem 0x steht.

3. Du verifizierst die Keys. Mit:

pacman-key -f <id>

schaust du dir den Fingerprint an und vergleichst sie mit dem Fingerprint auf der Seite.

4. Du vertraust den Key:

# pacman-key --edit-key <id>

dort dann 'trust 3' (oder auch 4,5) je nachdem, wie sehr du dem traust).

Speichern und abschließen mit 'save'

5. Du signierst die Keys

# pacman-key --lsign-key <id>

Das war's dann. Wenn du nun updates, wirst du gefragt, ob du die fehlenden Schlüssel importieren willst. Das kannst du bejahen. Die Schlüssel sollten mit den MAster-Keys signiert sein, so dass du denen automatisch traust.
müsste das bei punkt 2 bis 5 nicht auch pacman-key sein statt nur pacman?
Oh ja, stimmt natürlich.
Kinch schriebWenn folendes zu einem Key steht:
This key was revoked on 2011-11-19 by RSA key 824B18E8 Thomas Bächler (Arch Linux Master Key) <thomas@master-key.archlinux.org>
sub  1024R/AAE53976  created: 2011-11-19  revoked: 2011-11-19  usage: E   
This key was revoked on 2011-11-19 by RSA key 824B18E8 Thomas Bächler (Arch Linux Master Key) <thomas@master-key.archlinux.org>
sub  2048R/96A8F3F2  created: 2011-11-19  revoked: 2011-11-19  usage: A
Hat das was zu sagen?
Zumindest nichts, was den eigentlichen (Haupt)Schlüssel diskreditiert. Ich habe über die Bedeutung der einzelnen usage-Flags auf die Schnelle nichts gefunden, aber die revoke Meldungen beziehen sich *nur* auf Sub-IDs des Schlüssels. Hier wurde wohl einfach eine (schwache) SubID widerrufen und eine andere, evtl. zum Testen ob das Widerrufen mit/durch die MasterKeys möglich ist. Für mich als User ist eigentlich zum eigentlichen Schlüssel nur die Ausgabe von:
pacman-key -l <keyid> entscheidend (in Verbindung mit --list-sigs), hier würde sich rausstellen wenn der komplette Schlüssel (//Edit: bzw. der Schlüssel, dessen ID ich gerade prüfe) widerrufen wäre.

Zwei der MasterKeys haben diese revoke-Meldungen leider auch, was mit dem Meldungstext: "This key was revoked..." einen schlechten Beigeschmack gibt. Das revoke bezieht sich aber "nur" auf den folgenden Sub-Key ;-)
Wie ich irgendwo auf gpg-users gelesen habe gab es genau zu dem Meldetext die Überlegung dafür eben sowas wie "The following subkey was revoked..." zu verwenden. Dann wird das wohl klarer, weniger "dramatisch"...

//Edit2: revoke bedeutet hier, daß der ganze Schlüssel (oder wie oben gesehen auch nur Sub/UnterIdentitäten) widerrufen werden können/müssen wenn z.B. der Eigentümer nicht mehr gültig ist (oder bei einer Sub-ID die dazugehörige Email-Adresse) oder der Schlüssel kompromitiert ist (durch vergessen der Passphrase oder Verlust des privaten Schlüssellteils...)
Erstmal danke für die Anleitung oben Kinch. Ich hab jetzt die ganzen Masterkeys bei mir hinzugefügt, trusted (3) und auch lokal signiert. Wenn ich jetzt pacman -Su ausführe, reicht ihm das aber anscheinend nicht, dass die Pakete "marginal trusted" sind.
error: cmake: signature from "Dave Reisner <d@falconindy.com>" is marginal trust

In der pacman.conf hab ich "SigLevel = Optional TrustedOnly" ausgewählt.
@backfist:
mach mal ein: pacman-key --updatedb
Der Sig-Level sollte - wenn man Signierung verwendet <g> - momentan AFAIK noch "Required DatabaseOptional TrustedOnly" sein.
Hmm das hat leider beides nicht geholfen. Das Updaten der DB scheint pacman-key schon selber gut zu machen und das ändern des Sig-Level ist laut Wiki zwar korrekt, aber die Fehlermeldung bleibt die selbe.
Betrifft das nur das Paket cmake oder auch (alle) andere, die zur Installation anstehen?

Ich bin in den Internas von pacman nicht drin, aber die Fehlermeldung "vermeldet" ja eigentlich genau das als "Fehler" was die Mindestanforderung für den trustlevel (eben marginal) sein soll.
Evtl. könnte hilfreich sein die Ausgabe von: 
pacman --debug -S cmake 2>&1 | tee err.log
und den Inhalt von err.log dann mal nach pastebin o.ä. stellen damit man sich das mal ansieht.

Danach würde ich ggf. nochaml ein: pacman -Syyu antesten.
Weils IMHO so noch wenig im Forum rüberkam:
Ich finde es klasse, daß dieses langersehnte Feature nun bei pacman Einzug gehalten hat.
Wenn es auch hin und wieder noch klemmt *und* der Übergang - naturgemäß! - im "rolling release" geschieht: Danke an alle, die dazu beigetragen haben!
Kinch schrieb Das war's dann. Wenn du nun updates, wirst du gefragt, ob du die fehlenden Schlüssel importieren willst. Das kannst du bejahen. Die Schlüssel sollten mit den MAster-Keys signiert sein, so dass du denen automatisch traust.
Danke dir. Damit hab ich erst einmal signiert. Aber ich habe in der /etc/pacman.conf noch "SigLevel = Never" stehen. Damit werde ich beim Update noch nichts gefragt.
Was muss denn da jetzt rein? "SigLevel = Required DatabaseOptional TrustedOnly"? Oder das, was in der /etc/pacman.conf.pacnew steht?
Und muss es überall gleich sein? Ich habe die Repositorys core, extra, community, multilib und archlinuxfr.
also global einmal SigLevel = Optional TrustedOnly

Damit kannst du z.B. auch Pakete aus dem AUR installieren, die ja nicht signiert sind (falls man es nicht so einrichtet das selbstgebaute Pakete mit einem gültigen Schlüssel signiert werden). Optional heißt: Signatur muss nicht vorhanden sein, aber wenn eine da ist muss sie korrekt sein!

Bei den offiziellen Repos dann jeweils: SigLevel = Requierd DatabaseOptional TrustedOnly
Das heißt es muss eine korrekte Signatur vorhanden sein, Pakete ohne Signatur sind nicht erlaubt. Bei den offiziellen Repos sollten aber ja alle Pakete mit gültigen Schlüsseln signiert sein.


also in die pacman.conf 
SigLevel = Optional TrustedOnly

...
...
...

[core]
SigLevel = Required DatabaseOptional TrustedOnly
Include = /etc/pacman.d/mirrorlist

[extra]
SigLevel = Required DatabaseOptional TrustedOnly
Include = /etc/pacman.d/mirrorlist

[community]
SigLevel = Required DatabaseOptional TrustedOnly
Include = /etc/pacman.d/mirrorlist

[multilib]
SigLevel = Required DatabaseOptional TrustedOnly
Include = /etc/pacman.d/mirrorlist
Ob die Pakete in archlinuxfr mit Schlüsseln die mit den Masterkeys signiert sind erstellt werden weiss ich nicht.
In diesem Thread ist z.B. auch eine pacman.conf mit dem archlinuxfr Repo (die von Dirk Sohler). Er hat es mit Optional TrustedOnly drinnen 
[archlinuxfr] 
SigLevel = Optional TrustedOnly
Server = http://repo.archlinux.fr/$arch
OK. Vielen Dank. Ohne dieses Forum würde ich an Arch-Linux scheitern.
Nochmals danke.
hellmi666 schriebOhne dieses Forum würde ich an Arch-Linux scheitern.
dafür ist es ja da 😉
Kinch schriebAber das wichtige steht doch dort:

1. # pacman-key --init
2. Du holst dir die Master-Keys: https://www.archlinux.org/master-keys/
Für jeden Key einmal ein:

# pacman-key -r <id>

Die Id ist das was bei '0x6AC6A4C2' etwa, nach dem 0x steht.
Das habe ich probiert.
 pacman-key -r 6AC6A4C2
gpg: fordere Schlüssel 6AC6A4C2 von hkp-Server keys.gnupg.net an
gpg: Schlüsselserver-Zeitüberschreitung
gpg: Empfangen vom Schlüsselserver fehlgeschlagen: Schlüsselserverfehler
==> Aktualisiere Trust-Datenbank
gpg: "Trust-DB"-Überprüfung nicht nötig

🙁