[pacman-dev] [PATCH 1/3] Changed all references to signature verification level in libalpm symbols to 'verifysig'. Removed references to PGP in libalpm symbols. Signed-off-by: Kerrick Staley <mail at kerrickstaley.com>

[Kerrick Staley]

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.