Am Wed, 17 Dec 2008 18:22:36 +0530 schrieb Jatheendra <jatheendra@gmail.com>:
A patch for adding VerifySignature options in pacman.conf
From your other mail: ------------ These patches will add VerifySig option to pacman.conf. VerifySig takes options Always, Optional or Never [repo-name] Server = ServerName VerifySig = Always Include = IncludePath ------------ I've not tested your patch (today evening maybe), but i am not very happy with this triple state. If i choose to use a repo which offers signed packages then i want the "full program", so if something wrong with one package i don't want it get installed/upgraded. And if i have a repo without signing then i don't put the option in the repo section of pacman.conf. I found my suggestion has mor advantages, ex.: ------------ [core] Keyring = /etc/pacman.d/gpg/devel.gpg ... [community] Keyring = /etc/pacman.d/gpg/community.gpg ... [myrepo] ... [yaourt] Keyring = /etc/pacman.d/gpg/fr-repo.gpg ... ------------ a) The Keyring= Option indicates pacman if the signing framework should be used b) This var signals pacman where to find the public keyring for this repo. AND we could have different keyrings for repos. Ex.: the TU (if community packages get signed) fluctuation is IMHO bigger than on the Developers side. So keyring updates are more often necassary on community/TU side. And myself find it better to have the TUs signatures/trustlevel not in the same keyring like developers (core,extra) keyring for package signing. c) With this var a extern repo (ex. the france yaourt repo) could offers also signed packages - and a properly public keyring. I think a little further (currently in the phase were we not finished with programming to maybe avoid false paradigms): - How get the users the keyrings, how get they updated? - How is the trustdb(Trustlevel) handled? Must/should each user first sign each public key in the keyrings (Urghhh!)? Or is it better to deliver both signing framework files for a repo (ex. core): devel.gpg (=the keyring with public keys) and develdb-gpg (=the trustdb file). This trustdb file could could be the arch-web-of-trust where the arch leader for .ex. signes all devel keys, so they are trusted for this keyring pair.