[pacman-dev] Package checking options (was: Changed all references to signature verification level in libalpm symbols to 'verifysig'.)

[Dan McGee]

On Sun, Jun 12, 2011 at 3:15 AM, Kerrick Staley <mail at kerrickstaley.com> wrote:
> 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

This is absurd as far as configuration goes. Why would we have 126
separate directives for what boils down to one thing, which as Allan
and I said, could be called "CheckLevel"?

~~~~
CheckLevel = Required SignedPackage SignedDatabase NoAllowUnknown

[another-repo]
CheckLevel = Optional

[someones-repo]
CheckLevel = NoSignedDatabase AllowUnknown

[insecureRepo]
CheckLevel = Never
~~~~

SigPreviouslySigned- an interesting thought, but definitely not
something we need on first pass- there are also a multitude of issues
here considering everyone starts from a different point. If you want
to be protected against this kind of attack, just use
Required/Always/whatever we call it.
SigHashed- covered by my previous suggestion; here it would be
"CheckLevel = Required SignedDatabase NoSignedPackage"

> ========
>
> 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 have objections on your way of going about business here. I present
what i thought was a reasonable approach, got some feedback by Allan,
and then you attempt to throw something completely different at us
without really responding to what is wrong with my proposal.

I'm trying my hardest to not get seen as a stick in the mud and
impediment to progress here, but it is damn hard to keep my cool when
my years of experience with this codebase gets shoved aside without so
much as a "I don't think you considered this" bit of feedback. My
ideas tend to be backed by those years of experience, and adding
config options is not something we like to do willy-nilly, nor do we
want a complicated config file.

> 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.
The usual preference in C is to use bitflags for things like this.

> 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.
That is a pretty bold assumption. You do realize there are more repos
out there that are not provided by a distro that people might want to
use and have signatures involved, right?

-Dan