I inadvertently broke my email account when I configured git-send-mail, and I only just realized it. Everything I've sent to the list since then didn't go through, so I'm resending this message, originally sent June 5 (I edited/updated it). Whatever we call the variable doesn't really matter; I like SigLevel. I'm working on a patch that will implement the below behavior. It's just taking a while because it's somewhat complicated. ======== Config: # Action to take (warn or abort) when packages and databases are unsigned but were previously signed SigPreviouslySigned = warn # Action to take (accept, warn, or abort) when neither the package nor the database have a signature SigNoSignature = warn # Action to take (accept, warn, or abort) when a package is signed but the database is unsigned # SigDatabaseUnsigned = accept # Action to take (accept, warn, or abort) when a package is unsigned but has a SHA256 hash in a signed database # SigHashed = accept ======== A) When handling a given situation, there are three actions that can be taken: 1. The situation is accepted silently. 2. The situation is accepted with a warning. 3. Installation/update is aborted, unless an override flag is passed, in which case a warning will be given. B) For a database, consider whether it should have a signature: 1. If SigDatabaseUnsigned = abort, but the .sig file cannot be downloaded, then keep checking servers until a .sig can be gotten, and give a warning each time a .sig download returns a 404. 2. If not (1) but, based on the various config settings, having an unsigned database would result in more warnings or aborts than a signed one, then check servers for a .sig until you get a .sig or you get 3 404's; if you get 3 404's, rescan through the list from the beginning, not checking for .sig's this time. Again, give a warning whenever a 404 happens. 3. If not (1)/(2), don't check for .sig's. C) For a package, consider whether it should have a signature: 1. If the package was previously signed but now isn't, act based on SigPreviouslySigned. 2. For local packages, if the package indicates it should have a signature (mechanism to be implemented) but it doesn't, abort. D) Outcomes for package/database signature validity ("signed" means GPGME_SIGSUM_VALID w/ GPGME_VALIDITY_{FULL,ULTIMATE}; "unsigned" means GPGME_SIGSUM_KEY_MISSING or no signature present, "bad" means anything else): 1. The package or database or both have bad signatures. Abort (could happen during database unpacking; the rest only happen on package check). 2. The package and database are signed. Accept. 3. The package is unsigned but the database is signed and the database uses SHA256. Act based on SigHashed. 4. The package is signed but the database is unsigned. Act based on SigDatabaseUnsigned. 5. The package is unsigned and the database is unsigned. Act based on SigNoSignature. ======== Notes: I invented the config names more or less randomly; if you have strong objections, we'll change them, otherwise let's go with these. I won't implement the SigPreviouslySigned functionality in the initial patch, because it can be cleanly separated from the rest, and I'm unsure if it's desirable. I've made pmsiglevel_t into a struct with 4 enum members; I'm currently passing it around by value (not with pointers); please give me a heads-up if you don't think I should do it this way. No marginal signatures should come up, because I don't think we should use such signatures during the interim when not all developers have fully validated keys; a developer's key can just be excluded from pacman-keyring until it is fully validated. A more sophisticated scheme that makes accommodations for marginally trusted signatures in external repositories (and probably also on PKGBUILDS for makepkg) would probably not be useful [1]. Regardless, I'd prefer we finalize/ship this feature in the future (while possibly adding basic support for it in the git now). Expiring signatures/keys and are not really necessary and will just complicate things. -Kerrick Staley [1] A distinction should be made between key validity and trust of the UID. In most contexts, it is assumed that you fully trust the person identified by the UID: if you know someone's name and email address, then you can exact some sort of revenge on them (or at least publicly scorn them) if they do you harm. However, in this case, you may not want to trust a random person maintaining a small Arch repository halfway across the globe with the same access to your system that the Arch developers have, even if you do know their name and email. GnuPG has no mechanism for implementing this sort of distinction; GnuPG only tracks how likely it is that the key-UID relationship hasn't been falsified. GnuPG simply displays the UID when verifying a signature, and the user can then make a judgement based off the UID, but pacman will not display the UID by default, and it is cumbersome to check the UID for each upgrade. A mechanism built into pacman for UID trust would be nice, but it seems like it would be complicated to implement "properly". Managing marginally-trusted keys is not really needed in pacman, because users can just manage the key in their personal keyring during the brief period when it's not fully trusted, manually checking and upgrading packages if necessary (using --gpgdir "$GNUPGHOME"), and then import it into pacman's keyring once it's trusted. So, for now, we should assume keys in the keyring are trusted and their UID's identify a trusted person. We can implement something more complicated in the future if we want; I might take a stab at this after basic signing's up and running. Until such time, users should only import a key into pacman's keyring if they trust packages created by the person identified in the UID and they trust the key itself.